Become an early Java 9 expert: AJUG + vJUG + JUGs Worldwide Hackday Feedback on JDK 9 EA
alex.buckley at oracle.com
Wed Sep 20 01:54:26 UTC 2017
On 9/19/2017 2:55 PM, Mani Sarkar wrote:
> Last month (19th August 2017) AJUG and a number of JUGs worldwide with the
> help and support from vJUG, re-ran the "Become an early Java 9 expert"
Thank you AJUG and vJUG!
> You can find the feedback gathered in http://bit.ly/J9HackDay-AJUG-feedback,
> we have been trailing JDK 9 EA b181 (RC1).
A lot of feedback seems to boil down to "JDK command line tools are not
so easy to use; I want my IDE!". I don't mean to make light of people's
usability issues, but the module-related paths and flags in JDK 9 tools
tend to operate along similar lines as the paths and flags in JDK 8
tools -- it's just that a lot of people haven't set ANY paths and flags
for a long time.
I see there were some more open-ended questions and this one in
particular caught my attention:
Do I need to convert a legacy Java program to use named modules in order
to take advantage of the smaller images that jlink can create?
Mani: You will have to convert your applications to use Java 9’s modules
system in order to take advantage of JLink fully, although please play
around with older legacy apps to see what JLink produces (most likely
the whole JDK and not modularised pieces).
Simon: create an empty module with module-info.java and handcraft the
dependencies using requires and have jlink compile it. This is
experimental, would need to be tested to see how it works.
The direct answer to the question is "No, you do not need to convert a
legacy Java program to use named modules in order to take advantage of
the smaller images that jlink can create."
The Java runtime that's present in even the smallest image (just
java.base) still lets you to put your pre-existing JAR files on the
classpath and run them with java -cp. You do not need to turn your JAR
files into named modules. Even as traditional JAR files, they have
access to all the APIs that you would expect from such an image.
(Obviously if your JAR files try to use Swing on an image built from
just java.base, that won't work.) The reduced footprint and security
surface of the smaller image is plainly an advantage from jlink.
More information about the adoption-discuss