Become an early Java 9 expert: AJUG + vJUG + JUGs Worldwide Hackday Feedback on JDK 9 EA

[Alex Buckley]

Hi Mani,

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"
> hackday.

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.

Alex