Thursday, February 1, 2018

JDK 10 Release Candidate Phase

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:

Additional References


Charles Roth said...

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? :-)


@DustinMarx said...

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.


@DustinMarx said...

"What's new in Java 10: Episode 1" is a recent post with more discussion regarding the JEPs associated with JDK 10.

@DustinMarx said...

The first JDK 10 Release Candidate (Build 43) has been announced.