6407460: provide Collections helper methods for new interfaces in JDK 1.6

David Schlosnagle schlosna at gmail.com
Fri Jan 28 06:07:39 UTC 2011

Thanks for the feedback Brian and Rémi.

I'm assuming this would go into JDK 8 at the earliest, so there seems
to be some time to build out the test cases and other related missing
methods. Are JUnit tests acceptable (I see only a couple in
jdk/test/java/dyn/) or would you prefer the standalone tests that seem
to be the majority?

As I was incorporating some of the comments tonight, I noticed a
possible improvement to Collections.UnmodifiableList#subList to handle
cases where the underlying List's subList method returns a proper
RandomAccess List implementation and by using the unmodifiableList
method to wrap it appropriately. Similar changes could be made for
SynchronizedList and CheckedList. Should this be handled as a separate

         public List<E> subList(int fromIndex, int toIndex) {
-            return new UnmodifiableList<E>(list.subList(fromIndex, toIndex));
+            return unmodifiableList(list.subList(fromIndex, toIndex));

On another note, does anyone know what the typical turnaround time is
from submitting a signed SCA/OCA to being listed on
https://sca.dev.java.net/CA_signatories.htm? I see the list was last
updated on 2011/01/18, but the SCA java.net project now seems to be
locked in preparation for migrating to the new java.net system.


On Thu, Jan 27, 2011 at 12:44 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> On 01/27/2011 06:27 PM, Brian Goetz wrote:
>> Overall these look like good additions.  I haven't reviewed the code in
>> detail but a quick sanity check suggests that this is a good direction.
>>  There's definitely some more work needed on the testing (for example,
>> testing that the contents of x and unmodifiable(x) are identical, testing
>> that the unmodifiable collection reflects changes in the underlying mutable
>> collection, testing the sortedSet/navigableSet methods for
>> empty{Sorted,Navigable}Set, etc).
>> As to the concurrent collection interfaces, I don't think they're strictly
>> needed, but they do make sense.  The methods added by ConcurrentMap over Map
>> are all mutative, so immutableMap(concurrentMap) should produce the desired
>> behavior but not necessarily the desired contract.
> I think you can reduce the number of empty* methods given that
> Deque inherits form Queue and NavigableMap inherits from SortedMap.
> Also you forget some wildcards in unmodifiableDeque and
> unmodifiableNavigableMap.

More information about the core-libs-dev mailing list