6 ms·

Jigsaw Finally Arrives in JDK 9

96 points by alblue 11y ago

gravypod 11y 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 11y ago
  Java has a slow startup time. By breaking out modules, they will significantly be able to reduce the overhead.
  - mike_hearn 11y 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.
- stevoski 11y 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).
  - needusername 11y 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.
    - mike_hearn 11y ago
      The java.desktop module is going to be a prime candidate for further breakdown, probably after Java 9 I guess. It is huge and ships all 3 widget toolkits when most apps need only one.
      - needusername 11y ago
        What's the third one? I'm only aware of AWT and Swing. I though that JavaFX was already in its own modules. Is it really realistic to only use one toolkit when Swing is built on AWT and has AWT base classes? What bothers me more is that things like Java Beans are in java.desktop.
        mike_hearn 11y ago
        JavaFX is in java.desktop too
- ajkjk 11y 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.
- cpprototypes 11y 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 11y 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.
    - carey 11y ago
      If managing versioned module dependencies with Jigsaw is anything like OSGi, you really don't. I haven't read the former's documentation yet, though.
      - alblue 11y ago
        Many people were frustrated with OSGi because it explicitly made modularity up front and centre, and the majority of developers didn't want to worry about it. The modularity of Jigsaw - including different classloaders for modules - is pretty much exactly the same as with OSGi. The differences are largely syntax and lack of versioning at this point.
- chadrs 11y ago
  This is a good explanation and may even get you excited about jigsaw. https://www.youtube.com/watch?v=y8bpKYDrF5I https://www.youtube.com/watch?v=y8bpKYDrF5I
petejansson 11y ago
It's about time it got an update. https://www.w3.org/Jigsaw/ https://www.w3.org/Jigsaw/
- alblue 11y 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.
stevoski 11y 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 11y 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.
- aardvark179 11y ago
  I think accurate compile time checking of cross module class visibility is a very valuable new feature.
- needusername 11y ago
  Oracle already charges for premium parts of Oracle JDK: Flight Recorder, resource management, application class data sharing
- edem 11y ago
  Nor Maven or Spring Boot is a module system. OSGi is.
needusername 11y ago
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-December/005814.html 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_hearn 11y 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.

96 points by alblue 11y 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 11y ago
Java has a slow startup time. By breaking out modules, they will significantly be able to reduce the overhead.
- mike_hearn 11y 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.
stevoski 11y 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).
- needusername 11y 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.
  - mike_hearn 11y ago
    The java.desktop module is going to be a prime candidate for further breakdown, probably after Java 9 I guess. It is huge and ships all 3 widget toolkits when most apps need only one.
    - needusername 11y ago
      What's the third one? I'm only aware of AWT and Swing. I though that JavaFX was already in its own modules. Is it really realistic to only use one toolkit when Swing is built on AWT and has AWT base classes? What bothers me more is that things like Java Beans are in java.desktop.
      - mike_hearn 11y ago
        JavaFX is in java.desktop too
ajkjk 11y 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.
cpprototypes 11y 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 11y 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.
  - carey 11y ago
    If managing versioned module dependencies with Jigsaw is anything like OSGi, you really don't. I haven't read the former's documentation yet, though.
    - alblue 11y ago
      Many people were frustrated with OSGi because it explicitly made modularity up front and centre, and the majority of developers didn't want to worry about it. The modularity of Jigsaw - including different classloaders for modules - is pretty much exactly the same as with OSGi. The differences are largely syntax and lack of versioning at this point.
chadrs 11y ago
This is a good explanation and may even get you excited about jigsaw. https://www.youtube.com/watch?v=y8bpKYDrF5I https://www.youtube.com/watch?v=y8bpKYDrF5I

petejansson 11y ago

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

alblue 11y 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.

stevoski 11y 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 11y 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.

aardvark179 11y ago
I think accurate compile time checking of cross module class visibility is a very valuable new feature.
needusername 11y ago
Oracle already charges for premium parts of Oracle JDK: Flight Recorder, resource management, application class data sharing
edem 11y ago
Nor Maven or Spring Boot is a module system. OSGi is.

needusername 11y ago

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-December/005814.html 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_hearn 11y 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.