Bryce L Nordgren a écrit :
> I just checked this out as well. I'm not sure this is true. I mean they
> do have a HashedMap, which does extend java.util.AbstractMap. They justify
> it as follows: "This implementation improves on the JDK1.4 HashMap by
> adding the MapIterator functionality and man
[EMAIL PROTECTED] wrote on 06/07/2006 12:41:52
AM:
>
>- Jakarta duplicates many J2SE classes. They have their own
> implementation of HashMap, etc.
I just checked this out as well. I'm not sure this is true. I mean they
do have a HashedMap, which does extend java.util.AbstractMap. They ju
[EMAIL PROTECTED] wrote on 06/07/2006 12:41:52
AM:
> Which needs are we trying to solve?
Need #1: Type checking on collections.
Need #2: Synchronizing "owning" objects with a backing set.
> If the only thing we need is a
> listener to be used by our
> implementation only, I would prefers to av
Bryce L Nordgren a écrit :
> The GeoAPI uses Collections interfaces to implement aggregations in the UML
> from 19107. The way in which it uses them forces implementations to
> provide the actual data structure to clients because this is the only way
> to add component pieces (e.g. add points to a
Bryce L Nordgren wrote:
> dormant code. You can only get it from their subversion server. Lacking
> any better ideas, I exported it from their subversion server and plunked it
> into the geometry branch. So, PMC, how should we handle this? I think our
> options are:
>
> 1] Steal the code outrig
Here's a thinker for the PMC:
The GeoAPI uses Collections interfaces to implement aggregations in the UML
from 19107. The way in which it uses them forces implementations to
provide the actual data structure to clients because this is the only way
to add component pieces (e.g. add points to a po
