Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

[Alan Bateman]

On 10/09/2015 17:15, Mani Sarkar wrote:
> Hi Rory,
>
> I have played with the Jigsaw JDK using the Quick starter guide and 
> have this to share with our community:
> https://github.com/neomatrix369/jdk9-jigsaw
>
> There is a small mistake in the example on Services (see my 
> implementation you will spot it soon), also the Services example 
> explains more than one concept at a time and I think this might just 
> be a bit more than a simple example to illustrate Jigsaw features.
>
> The last two examples are not fully fleshed out. I would put a 
> footnote about jlink, that jmod + tools are going to supersede jimage 
> (if from what I have read so far is correct, I have even seen this 
> mentioned on a JBUG issue).
>
I don't immediately see the error in the services example (I need to 
look closer) but I think you have a point that this example jumps ahead 
too much. Good idea to get the examples into a repo with scripts.

Just on the tools then jlink + jmod don't supersede the jimage tool. 
Lots of new j- tools so the following might be helpful:

jlink is the linker. It links a set of modules together to create a 
run-time image, the layout of which is described in JEP 220. The jlink 
tool is in the current EA builds but no documentation to point at yet. 
There will be a JEP in time (as mentioned already in JEP 261). The jlink 
example you see in the quick start page should work and create a 
run-time image that contains module com.greetings and its transitive 
dependences. Another thing to mention is that the jigsaw/jake builds 
invoke jlink to create the JDK, JRE, and compact profile images. I think 
of jlink as a tool for the advanced tool chain and not something that 
most developers will use directly.

The jmod tool is to the JMOD format as the jar tool is to the JAR 
format. In the jigsaw/jake build then you'll see that the tool is used 
to create a JMOD for each standard and JDK-specific module. The 
directory of JMOD files then serves as the module path for the linker 
when it creates the JDK and JRE images. Like jlink then I don't expect 
too many developers to need to use the jmod tool or JMOD format as 
modular JAR files will do just fine for most modules. In the example in 
the quick start page then the only reason that the JDK jmods directory 
is on the module path is because creating a custom image requires 
resolving standard and maybe JDK modules so the tool needs to be able to 
locate the corresponding module artifacts.

Now jimage. In a run-time image (JEP 220) then classes and resources are 
stored in a container that is in jimage format. The format is 
deliberated not documented and best to assume it will change and evolve 
over time as it inhales new optimizations. Introducing a new container 
format is a bit scary and needs some tooling to aid troubleshooting in 
the event of problems. This is why the JDK 9 builds and the EA builds 
have a jimage tool. It can be used to do some verification, list or 
extract the contents. It's not meant to be on par with the jar tool of 
course. Instead just think of the jimage tool as First Aid Kit hanging 
on the wall in the event that you might need it.

-Alan.