Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8046098

JEP 108: Collections Enhancements from Third-Party Libraries

    Details

    • Type: JEP
    • Status: Closed
    • Priority: P4
    • Resolution: Withdrawn
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
      None
    • Author:
      Mike Duigou
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Scope:
      SE
    • Discussion:
      core dash libs dash dev at openjdk dot java dot net
    • Effort:
      M
    • Duration:
      L
    • JEP Number:
      108

      Description

      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.

        Issue Links

          Activity

          There are no comments yet on this issue.

            People

            • Assignee:
              mduigou Michael Duigou
              Reporter:
              mduigou Michael Duigou
              Owner:
              Michael Duigou
              Endorsed By:
              Brian Goetz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: