Jigsaw Finally Arrives in JDK 9

http://www.infoq.com/news/2016/03/jigsaw-jdk-9

by alblue • 10 years ago

96 46 10 years ago

gravypod• 10 years ago

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.

melling• 10 years ago

Java has a slow startup time. By breaking out modules, they will significantly be able to reduce the overhead.

mike_hearn8• 10 years ago

Java starts in about 50 msec. Modularity won't make much if any difference to that.

The primary benefits are better security, encapsulation and the jlink tool that lets you build standalone app-specific bundled JREs.

stevoski2• 10 years ago

You'll no longer need to distribute the entire JRE API if your app needs an embedded JRE. You'll be able to distribute only the modules you need.

For example, I'll no longer be including the useless (for most Java apps) CORBA capability with my product. A server-side product will be able to exclude the desktop GUI API (AWT and Swing).

needusername7• 10 years ago

A server-side product will be able to exclude the desktop GUI API (AWT and Swing).

That is very unlikely. If you look at the java.desktop module (where things like AWT and Swing are) there are also tons of other things there like Java Beans. A lot of Software requires Java Beans at least indirectly (eg. Spring requires Java Beans). In addition there's the following dependency path. java.xml.ws -> java.xml.bind -> java.activation -> java.desktop A server side product is very likely going to require at leat one of these. The fact of the matter is that the JDK code is simply not modular enough.

ajkjk• 10 years ago

Not an expert but here's my version:

Currently if you want to deploy software running in the JDK, you're forced to pick up the whole JDK, which is terrible if you want to deploy as small a codebase as possible, especially because literally nobody is using Swing and AWT and Nashorn in server-side environments.

Meanwhile, currently if you want to use a module system that only deploys code you're actually transitively dependent on in Java, you have to roll your own with its own concept of dependency and versioning.

Meanwhile, currently if you want to depend on a library that's already deployed on a host, you get to discover it via the classpath mechanism, which has an element of.. randomness.. to it, and in some cases if you have two versions of the same class in your classpath you can get some very strange and hard-to-debug behavior. (I've had colleagues who wrote custom classloaders purely to work around this in the constraints of our dev environment) This combines especially badly with the ubiquitous use of 'discovery' mechanisms in enterprise Java such as static logger binding or classpath-scanning for annotations to find configurations and bean definitions.

Meanwhile, currently, the 'public' designation in a module means public to everyone in every module, and if you want to avoid that and go package-private or less, you have to be private even within other packages of your own module, since package-private is not inherited by subpackages (com.me.x and com.me.x.y do not actually 'inherit' in any sense). That is, there's no distinction between 'public' and 'exported' types.

Jigsaw attempts to address all of these. I haven't followed it closely enough to comment on whether I think it's the ideal solution, but, it's definitely the right direction if Java is to continue being used everywhere - which it is, because it's deeply entrenched and (while not as modern as some would like) it's getting the job done.

cpprototypes2• 10 years ago

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.

umanwizard• 10 years ago

That is amazing. Wow. It almost makes me wish I was still working in Java. This was one of the biggest pain points back when I was.

papercrane• 10 years ago

Good explanation. There are currently ways to manage the issues, OSGi, classloader hacks, or using something like Maven's shade plugin. They all have their own issues and pain points though.

The other thing that Jigsaw is bringing is modularizing the standard library as well. So if you don't want CORBA in your runtime image than you can leave it out.

alblue6• 10 years ago

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.

lisivka• 10 years ago

I am 100% sure Jigsaw will not let you to do that stupid thing. Import statement has no version information, so your program will load json-lib 1.0 or 1.2 and then random errors will start to happen. It's called Dependency Hell: https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell

needusername7• 10 years ago

Nobody actually forces you to use the classpath. You can just set up a custom classloader and no whatever you want. Basically all containers do this.

chadrs• 10 years ago

This is a good explanation and may even get you excited about jigsaw.

https://www.youtube.com/watch?v=y8bpKYDrF5I

petejansson• 10 years ago

It's about time it got an update. https://www.w3.org/Jigsaw/

alblue6• 10 years ago

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.

stevoski2• 10 years ago

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.

diebir• 10 years ago

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.

aardvark1793• 10 years ago

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

needusername7• 10 years ago

Oracle already charges for premium parts of Oracle JDK: Flight Recorder, resource management, application class data sharing

edem• 10 years ago

Nor Maven or Spring Boot is a module system. OSGi is.

needusername7• 10 years ago

Mark Reinhold has compiled a list of some 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...

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.

mike_hearn8• 10 years ago

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.

Jigsaw Finally Arrives in JDK 9

Related Stories