Mark Reinhold's mailing list message "JDK 10 Release Candidate Phase: Process proposal" was posted today and opens with the sentence, "Per the JDK 10 schedule, we'll enter the Release Candidate Phase next week, on Thursday, 8 February." Reinhold proposes that the JDK 10 Release Candidate Phase be enacted in the same manner as the JDK 9 Release Candidate Phase and he provides a link to the (proposed) "JDK 10 Release-Candidate Phase" page. That page outlines the proposed processes associated with the JDK 10 Release Candidate Phase with specific focus on the level of bug fixes targeted for JDK 10. The bugs are categorized as P1 through P5 and once the JDK 10 Release Candidate Phase is entered, "all P2-P5 bugs must be left to future releases" and the focus will be on fixing "all P1 bugs that are new in JDK 10 and critical to the success of the release."
At the time of this writing, the following twelve features are targeted for JDK 10 as we're about to enter the Release Candidate Phase:
- JEP 286: Local-Variable Type Inference
- JEP 296: Consolidate the JDK Forest into a Single Repository
- Described by Ben Evans as "purely housekeeping."
- JEP 304: Garbage-Collector Interface
- "Improve the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface."
- JEP 307: Parallel Full GC for G1
- Release Note: JEP 307: Parallel Full GC for G1: "With JEP 307 the full GC has been parallelized and now use the same amount of parallel worker threads as the young and mixed collections."
- JEP 310: Application Class-Data Sharing
- "To improve startup and footprint, extend the existing Class-Data Sharing ("CDS") feature to allow application classes to be placed in the shared archive."
- JEP 312: Thread-Local Handshakes
- "Make it both possible and cheap to stop individual threads and not just all threads or none."
- JEP 313: Remove the Native-Header Generation Tool (javah)
- Replaced by JDK 8's addition of javac support for generating native headers
- JEP 314: Additional Unicode Language-Tag Extensions
- "Add support for ... additional extensions: cu (currency type), fw (first day of week), rg (region override), tz (time zone)."
- JEP 316: Heap Allocation on Alternative Memory Devices
- "Enable the HotSpot VM to allocate the Java object heap on an alternative memory device."
- JEP 317: Experimental Java-Based JIT Compiler
- "Enable the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform."
- JEP 319: Root Certificates
- "Open-source the root certificates in Oracle's Java SE Root CA program in order to make OpenJDK builds more attractive to developers, and to reduce the differences between those builds and Oracle JDK builds."
- JEP 322: Time-Based Release Versioning
- "Feature releases ... contain new features"
- "Update releases ... only fix bugs"
Additional References
- Java 10 Checklist: Meet the Declaration That Will Change the Way You Code (January 2018)
- 9 code and framework trends to watch in 2018 (January 2018)
- It's a done deal! The next Java version will be JDK 10 (December 2017)
- What's Planned for JDK 10? (November 2017)
- Java 10 - The Story So Far (November 2017)
4 comments:
Thank you for the summaries! I'll keep an eye on this blog (got here courtesy of your article on multiple returns and Java 8 Optional).
Don't know where else to ask this, and you seem very knowledgeable about the new-java-releases-development-path :-) ... so...
Do you think we'll ever see unit-tests become first-class citizens in Java? More precisely, will we ever see something like the C++ "friend" privacy modifier?
Java, as it stands, makes it difficult to make methods with privacy restrictions, yet still visible to tests. Yes, in theory a greenfields all-TDD project might never need that (testing only through public interfaces), but in the real world of legacy Java code, I need to write tests for methods that are not public.
Does the question make sense? Do you have any thoughts, suggestions, or whom to bribe to at least think about adding something like this to Java? :-)
Thanks!
Hello Charles,
That's not something I'd expect anytime soon in Java because I haven't read or seen anything recently on the effort to do something like that. As you say, it's particularly difficult with legacy Java projects written without testing in mind. I think most people work around this with mocking frameworks (PowerMock for the most difficult), but it might be nice to have techniques built into the language that are easier to use than custom classloaders and bytecode manipulation. It seems to be a recent trend in newer languages such as Rust and D to provide more built-in test support.
The first step to get something like this considered for Java might be to ask about interest in it on one of the JDK mailing lists such as core-libs-dev or jdk-dev.
Dustin
"What's new in Java 10: Episode 1" is a recent post with more discussion regarding the JEPs associated with JDK 10.
The first JDK 10 Release Candidate (Build 43) has been announced.
Post a Comment