
Jigsaw Finally Arrives in JDK 9 - alblue
http://www.infoq.com/news/2016/03/jigsaw-jdk-9
======
stevoski
For ten years, the team who produce Java have been trying to modularise Java.
Time after time they've run into big problems and the project has delayed or
shelved. I hope, finally, they manage to succeed this time.

It seems adding modularisation to a product of the nature and scale of the
Java API, while maintaining backward compatibility, is very hard.

------
needusername
Mark Reinhold has compiled a list of some issues:

[http://openjdk.java.net/projects/jigsaw/spec/issues/](http://openjdk.java.net/projects/jigsaw/spec/issues/)

Of special note is Springs need for optional dependencies. Previously several
other projects requested this but always got shot down by Oracle with "we
didn't find any need for this in the JDK". AFAIK optional dependencies are
still not planned.

[http://mail.openjdk.java.net/pipermail/jigsaw-
dev/2015-Decem...](http://mail.openjdk.java.net/pipermail/jigsaw-
dev/2015-December/005814.html)

In addition the SWT/AWT Bridge that Java Mission Control which ships with
OracleJDK uses requires special JVM flags to run with break up modularity. I'm
not aware of any plans to fix this.

------
gravypod
What are they attempting to accomplish with Jigsaw? I've read many sources but
each has it's own interpretation of what it will do.

~~~
cpprototypes
My understanding of the practical benefits is this (someone please correct me
if I'm wrong)

Java currently doesn't have true packages. There's namespacing
(com.companyname.abc.xyz), but it's all on a single classpath (java -cp).
Dependency management like Maven gives somewhat of an illusion of packages.
The end result of a Maven build is still a bunch of jars running with "java
-cp".

For example, in Maven, imagine there's a json-lib 1.0 and 1.2. Library A needs
json-lib 1.0 and Library B needs json-lib 1.2. Project X is using both Library
A and Library B and when Maven tries to build, there will be a version
conflict between json-lib 1.0 and json-lib 1.2. There are no good options at
this point because the single classpath forces the selection of one version
for json-lib. The developer has to either pick json-lib 1.2 and hope Library A
can run with it. Or pick json-lib 1.0 and hope Library B can run with it. This
is assuming Library A and Library B are external libraries that the developer
has no control over and hasn't been updated in a long time.

With packages (Jigsaw), it's possible to let both versions exist in a project.
It will be possible for Library A to be a package and use json-lib 1.0. And
Library B will be another package and can use json-lib 1.2. During runtime,
each package will have an isolated classpath and so the dependencies won't
conflict. I'm assuming the Maven developers will update Maven to do this once
Java 1.9 is released.

This will remove a big headache that currently exists for Java developers. The
chances of a version conflict approaches 100% as the number of dependencies
grows in a project.

~~~
alblue
Just as a heads up; Jigsaw (as it is today) doesn't have versions, so the
issues you describe won't happen. There will be one global json-lib module
that will be available to all modules.

They've taken enough to get to this point that adding version numbering isn't
going to happen, but it doesn't rule it out adding it in the future. They did
the minimum necessary to split out the Java libraries into different modules
but no more.

If you want to have versioned dependencies, you have to work with a module
system that understands versions, like OSGi.

~~~
merb
actually you still could run two json-lib modules, you create module1 which
depends on json-lib1 but doesn't reexport it and module2 depends on json-lib2
but doesn't reexport it. done.

~~~
alblue
But then they would be two different modules; not the same module with
different version numbers.

~~~
oldmanjay
In this situation, the difference between those two descriptions seems more
spiritual than practical.

~~~
alblue
Not really; a module system that has versions allows you to define
dependencies in terms of version ranges, so that if installing a newer version
into your app the module can decide in its dependencies if the version is
compatible or not. If you are spinning up different names for each
module/version then you have to go round updating all your code that depends
on the module to use the different name, and you can't select a different one.
The point was that Jigsaw doesn't have a concept of version numbers in its
module dependency system; they are all dependent upon exact name only.

------
mike_hearn
Probably the neatest part of Jigsaw is not the actual module system itself,
but the tools it makes possible, specifically the "jlink" static linker. Jlink
creates custom JRE images that:

• Don't have unused modules

• Don't use JARs as a format, instead using a much more optimised internal
binary format

• Have various whole-program optimisations done on them, like removing the use
of reflection.

• Can produce native Mac/Win/Linux installers/packages.

The last one is already a feature of Java 8 via the javapackager tool, but
jlink makes it a much more powerful system.

------
diebir
Oh, I don't have a good feeling about this...

First, I am worried that instead of being able to just assume that "all of
Java is there", there will be "no we just did a minimal install". Second,
after watching the video briefly, we may already have tools for most of what
this tries to solve (Maven, Spring boot, etc). Third, I suspect that there's
some sort of nefarious scheme by Oracle to start charging for "premium" parts
of JVM.

My initial feeling: it works just fine now, don't fix it. Or maybe I am wrong
and it will be great.

~~~
aardvark179
I think accurate compile time checking of cross module class visibility is a
very valuable new feature.

------
petejansson
It's about time it got an update.
[https://www.w3.org/Jigsaw/](https://www.w3.org/Jigsaw/)

~~~
alblue
That is something completely different. The Jigsaw referred to in the title is
the Java module system that will be part of Java 9, not a GUI browser made by
a different group.

