mhm.. to my knowledge the collection is the super class, thus lists have
more methods.
so you can not cast from collection to list but the other way around???
stefan
Sunburned Surveyor schrieb:
> Stefan,
>
> I'm a little confused. A List is an implemenation of the Collection
> interface. I tho
Stefan is correct that Lists have more methods, although technically
Collection is an interface not a super class. The List interface is a
superset of the Collection interface. Notably it adds the important
positional access methods. Of course, Lists also have order which all
Collections do not
I'm not trying to say that there on only one right way to do things,
however the basic JUMP design is a very good one, and consistency in
return values for the methods of a class is not necessarily something
to strive for.
In the case of getFeatures(), the main accessor method of the class,
it is
I have started work on the New Feature Documentation. I am organizing the
documentation into "topics", with most topics covering a single new feature.
Some of the topics may cover more general topics. For example, one of the
topics I am writing will be "Working With Selections On OpenJUMP's
LayerV
I'm want to get in the habbit of writing unit test for [1] the new classes I
create for OpenJUMP, and [2] the existing JUMP/OpenJUMP classes that I work
with. I am not an expert with JUnit, so I was hoping to get some help from
other OpenJUMP Developers. (If there are some of the GeoTools develope
Yep, I'd vote for that package structure. I've used it in the past, and
it works well.
Sunburned Surveyor wrote:
> I'm want to get in the habbit of writing unit test for [1] the new
> classes I create for OpenJUMP, and [2] the existing JUMP/OpenJUMP
> classes that I work with. I am not an expe
