Summary

Evolve the Java Collections Framework by adopting common and popular functionality from third-party libraries.

Goals

• Our position should be that the Java Collections Framework provide a broad array of functionality to satisfy the core needs of most Java developers.

• JCF remains the primary source for collection classes.

• Java developers are not forced to rely upon 3rd party libraries.

Non-Goals

The goal is not to eliminate 3rd party libraries. There will always be functionality that we choose not to include in JDK and library authors will always continue to develop new libraries.

Success Metrics

• JCF remains the primary source for collection classes. Java developers are not forced to rely upon 3rd party libraries.

• Adoption of the new functionality by Java developers.

Motivation

The small improvements to the java.lang utilities such as Objects.requireNonNull have been very well received already. These type of improvements are very much appreciated by working Java developers. We will be adopting the "best bits" from 3rd party libraries. This serves to reduce the need or demand for those libraries.

Description

Two categories of "Best Bits" will be adopted:

• Convenience functions and idioms to make using the existing functionality easier, simpler or more performant.

• Import a very small number of important general data structures if any can be identified and as time permits. The most likely candidate structures are; MultiMap, Multiset, BidiMap/BiMap. MultiMap and MultiSet are useful for bulk data operations. It is reasonable to drive implementation of these features based upon the urgency of need (or conversely lack of need) by other parts of the JDK.

Alternatives

Have Java depend upon 3rd party collections libraries as is done with XML, portions of JCE (NSS), and JavaScript (Rhino).

Testing

Standard for Java Collections Framework.

Risks and Assumptions

The biggest risk is in the requirements imposed by JEP 107 which are not yet fully determined. Perhaps this should be split into two JEPs, one low risk and second for as yet undetermined functionality.

Dependences

This proposal is partly in support of JEP 107. The requirements for new data structures will be driven by the needs of that JEP.

Impact

• Other JDK components: Some refactoring to use the new features will be warranted.
• Compatibility: Forward compatible only. No backwards incompatible changes will be introduced.
• Performance/scalability: Standard for JCF
• Portability: Java code only. No native code.
• Documentation: Standard
• TCK: New tests required. No special requirements.