JDK 12 patrol: Packaging Tool joins the party
JDK 11 is almost upon us but that’s no excuse to chill! The tech world is moving fast and we ‘re in for the ride! The JDK 12 development repositories are open and we thought it’s time to start a new thread in order to keep track of everything that’s going live. Today we add one more JEP candidate to the list. Let’s take a closer look!
The countdown to JDK 11 is almost over but we just can’t stand still!
It is time to add one new JEP candidate for JDK 12.
When I migrated frm Java7 to Java8 you had launched version 10 and now when I m thinking for 10 u r launching JDK12. 😀
— Ratnesh (@ratneshkush) September 3, 2018
To be perfectly clear, JDK 12 is not set up for release yet, but we definitely feel your struggle, friend!
The development repositories are open for bug fixes, small enhancements, and JEPs so it is time for a new thread to keep track of everything that goes live.
And since JDK 11 will be featuring 3 JEP contributions from the community (the largest number of community contributions to a release so far) let’s keep up the pace!
Today is another chill day for JDK 12 since we are only adding one new JEP candidate. But let’s take a look!
- JEP 343: Packaging Tool
JEP 343: Packaging Tool
Summary: Create a new tool for packaging self-contained Java applications. The
jpackager tool will take as input a Java application and a Java run-time image, and produce a Java application image that includes all the necessary dependencies.
Update September 11, 2018
JEP 340: One AArch64 Port, Not Two
Summary: Remove all of the sources related to the
arm64 port while retaining the 32-bit ARM port and the 64-bit
JEP 341: Default CDS Archives
Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.
JEP 342: Limit Speculative Execution
Summary: Help developers and deployers defend against speculative-execution (“Spectre”) vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases.
Update September 5, 2018
Proposed to target
Granted, two features may not seem like much but we’re just getting started!
JEP 325: Switch Expressions (Preview)
Summary: Extend the
switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in
switch. This will be a preview language feature.
SEE ALSO: “Developers will see Java 11 as a better, cleaner implementation of the features they use in Java 8”
JEP 326: Raw String Literals (Preview)
Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as
\n, or Unicode escapes, of the form
\uXXXX. This will be a preview language feature.
While we are on the JDK 12 topic, don’t miss our interview series about Project Skara. What do you think is the most beneficial alternative SCM and code review for the JDK source code? Check out what the experts had to say.
The results of the JAXenter poll seem to be pretty clear. Git wins. That’s it. No further explanation needed.
On the other hand, the three interviews we had with Java experts paint a not-so-crystal-clear picture. Let me explain.
In the first interview, we talked to Java Champion and JavaOne Rock Star speaker Stephen Colebourne, who seems to be rather enthusiastic about the prospect of migrating JDK source code management to Git.
From my perspective, I think using Git instead of Mercurial is a great idea. I can’t see any case to move to any other SCM.
However, for our second interview, we caught up with OpenJDK Author Patrick Reinhart who based his view mostly on the popularity of Git as opposed to Mercurial.
For new contributors, Git seems to be more tool-friendly than Mercurial is at the moment.
For our last interview, that went online just yesterday, we talked to OpenJDK committer Thomas Stüfe, who seems to have a rather conservative opinion on the matter.
I see no pressing technical reasons to switch to Git. I work with both SCMs and to me, none has a clear lead in performance or functionality.
See all the interviews here:
- Stephen Colebourne: “Using Git instead of Mercurial is a great idea”
- Patrick Reinhart: “Git seems to be more tool-friendly than Mercurial at the moment”
- Thomas Stüfe: “I see no pressing technical reasons to switch to Git”