Re: Improved Java Collection APIs

[David Holmes]

John Platts said the following on 11/20/10 01:49:

Here are improvements that I really want to see to Java Collection APIs:
- Additional concurrent collection classes. Some of these classes
will require synchronized modification, while supporting thread-safe
unsynchronized access and concurrent iteration.


That's a somewhat vague request. If you have specific ideas/suggestions 
here feel free to raise them on the concurrency-inter...@cs.oswego.edu 
mailing list where Doug Lea and the JSR-166 EG will see them (along with 
a large chunk of the community interested in concurrent collections).



- Support for collections synchronized on a read-write lock.


Again can you be more specific? Read-write locks sound theoretically 
useful for some collection operations but the devil is in the details. 
Unlike synchronized collections you can't necessarily just use a wrapper.


David Holmes

Re: Improved Java Collection APIs

[Dr Andrew John Hughes]

On 19 November 2010 15:49, John Platts  wrote:
>
> Here are improvements that I really want to see to Java Collection APIs:
> - Addition of an equality comparator interface.
> - An wrapper that wraps a java.util.Comparator as a equality comparator.
> - Map and set classes that allow an equality comparator to be used instead of 
> the equals() method or identity comparisons
> - New map and set interfaces that behave like the existing java.util.Map and 
> java.util.Set interfaces. Unlike the contract of the java.util.Map and 
> java.util.Set interfaces, the contract of the new map and set interfaces will 
> not require that o1 be considered to be equal to o2 when o1 != o2 and 
> o1.equals(o2) are both true. The new map and set interfaces will still 
> require that o1 be considered equal to o2 whenever o1 == o2 is true.
> - New collection interfaces which define versions of search and removal 
> operations that take an additional equality comparator argument. This enables 
> search and removal operations to use an equality comparator to determine 
> equality instead of relying on the equals method, an identity comparison, or 
> the java.util.Comparator.compare method.
> - Additional concurrent collection classes. Some of these classes will 
> require synchronized modification, while supporting thread-safe 
> unsynchronized access and concurrent iteration.
> - Support for collections synchronized on a read-write lock.
> - Addition of methods that iterates through the collection and invokes a 
> callback. This is useful in cases where the callback object can be 
> pre-allocated, since iteration using a java.util.Iterator object usually 
> requires an iterator to be allocated each time an iteration takes place.
>

Feel free to post patches to add these features.  Then they can be
reviewed and maybe added to the JDK.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: Improved Java Collection APIs

[Rémi Forax]

Le 19/11/2010 16:49, John Platts a écrit :

Here are improvements that I really want to see to Java Collection APIs:
   


[...]


- Addition of methods that iterates through the collection and invokes a 
callback. This is useful in cases where the callback object can be 
pre-allocated, since iteration using a java.util.Iterator object usually 
requires an iterator to be allocated each time an iteration takes place.



This one is on the task list of the lambda JSR, the callback will be 
expressed as a lambda.


Rémi