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.
