JEP 266: More Concurrency Updates
|Status||Closed / Delivered|
|Component||core-libs / java.util.concurrent|
|Discussion||core dash libs dash dev at openjdk dot java dot net|
|Reviewed by||Chris Hegarty, Martin Buchholz, Paul Sandoz|
|Endorsed by||Brian Goetz|
|Relates to||JEP 193: Variable Handles|
An interoperable publish-subscribe framework, enhancements to the
CompletableFuture API, and various other improvements.
The continual evolution of uses of concurrency and parallelism in applications requires continual evolution in library support.
Interfaces supporting the Reactive Streams publish-subscribe framework, nested within the new class
Flow, along with a utility class
SubmissionPublisherthat developers can use to create custom components. These (very small) interfaces correspond to those defined with broad participation (from the Reactive Streams initiative) and support interoperability across a number of async systems running on JVMs. Nesting the interfaces within a class is a conservative policy allowing their use across various short-term and long-term possibilities. The proposed
java.util.concurrentcomponents have been offered in pre-release since January 2015, and have benefitted from several rounds of review. There are no plans to provide network- or I/O-based
java.util.concurrentcomponents for distributed messaging, but it is possible that future JDK releases will include such APIs in other packages.
Enhancements to the
CompletableFutureAPI to address common complaints and suggestions since introduction its in JDK 8: Support for delays and timeouts, better support for subclassing, and a few utility methods. These have also been under review since January 2015.
Various improvements accumulated since JDK 8; many of them are small, but some include Javadoc spec rewordings.
Preliminary versions of these components are available via links on the Concurrency Interest (JSR 166) site.
The continuing set of JSR 166 EG members provide functionality, TCK, and performance tests for all components.
Risks and Assumptions
Care will be taken to ensure any small but required differences in code between the JDK 9 repository and the 166 repository are retained.