7 ms·

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 (co

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.
papercrane 11y 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.
- paulddraper 11y ago
  What's the downside to OSGi? And isn't that classloader magic?
  - brianwawok 11y ago
    Have you used OSGi?
    - paulddraper 11y ago
      Yes. I just don't know why Jigsaw is far better, other then it being part of the language of course. Perhaps ignorance on my part.
      - sheenobu 11y ago
        One thing I remember is the idea that Jigsaw is specifically for modularizing the JVM and JDK itself while OSGI would be for modularizing applications built on the JVM. Here is an article about this but it I would admit it is OSGI biased: http://njbartlett.name/2015/12/03/jigsaw-is-a-shibboleth.html http://njbartlett.name/2015/12/03/jigsaw-is-a-shibboleth.htm...
      - alblue 11y ago
        It isn't really but aimed at a different use case. Everyone rallied against OSGi because the strict modularity showed developers that in general their application wasn't as modular as they thought it was; and the fact that class loaders enforced that permissioning model showed where random Class.forName and module busting code lived. Guess what? Those developers will have exactly the same problems with Jigsaw modules. What Jigsaw will do is educate Java developers that the pain points are in strict modularity rather than any one module system.
alblue 11y 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.
- merb 11y ago
  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 11y ago
    But then they would be two different modules; not the same module with different version numbers.
    - oldmanjay 11y ago
      In this situation, the difference between those two descriptions seems more spiritual than practical.
      - alblue 11y ago
        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.
  - 11y ago
lisivka 11y 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 https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell
- aardvark179 11y ago
  Jigsaw will not let you do it in a vanilla configuration, but does allow for layers which do enable this. There is recognition that a single program should not hit this scenario but that app servers and similar may need to support it.
  - mike_hearn 11y ago
    It's not really only app servers and other plugin systems that need this. Dependency conflicts happen routinely when building all kinds of Java apps, just by depending on useful open source libraries. This is one of the pieces of feedback I sent to the Jigsaw team and I'm glad to see it appeared in Mark's list of issues to consider. Gradle's dependency tools help, but the best it can do is either flag an error or automatically de-conflict modules by always picking the newest version. If the version isn't fully backwards compatible, you can get deadlocked.
    - aardvark179 11y ago
      I'm torn on this. On one hand the sort of multiple version support offered by OSGi can be very useful, but equally debugging and coverage tools can quickly become confused because they may not cope well with multiple classes with identical names, and that ignores the fun of conflicting native libraries. So for the first version I'd be happy to see this left to frameworks sitting above the module system, but I can appreciate other view points.
needusername 11y 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.

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.

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

paulddraper 11y ago
What's the downside to OSGi? And isn't that classloader magic?
- brianwawok 11y ago
  Have you used OSGi?
  - paulddraper 11y ago
    Yes. I just don't know why Jigsaw is far better, other then it being part of the language of course. Perhaps ignorance on my part.
    - sheenobu 11y ago
      One thing I remember is the idea that Jigsaw is specifically for modularizing the JVM and JDK itself while OSGI would be for modularizing applications built on the JVM. Here is an article about this but it I would admit it is OSGI biased: http://njbartlett.name/2015/12/03/jigsaw-is-a-shibboleth.html http://njbartlett.name/2015/12/03/jigsaw-is-a-shibboleth.htm...
    - alblue 11y ago
      It isn't really but aimed at a different use case. Everyone rallied against OSGi because the strict modularity showed developers that in general their application wasn't as modular as they thought it was; and the fact that class loaders enforced that permissioning model showed where random Class.forName and module busting code lived. Guess what? Those developers will have exactly the same problems with Jigsaw modules. What Jigsaw will do is educate Java developers that the pain points are in strict modularity rather than any one module system.

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

merb 11y ago
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 11y ago
  But then they would be two different modules; not the same module with different version numbers.
  - oldmanjay 11y ago
    In this situation, the difference between those two descriptions seems more spiritual than practical.
    - alblue 11y ago
      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.
- 11y ago

lisivka 11y 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 https://en.wikipedia.org/wiki/Java_Classloader#JAR_hell

aardvark179 11y ago
Jigsaw will not let you do it in a vanilla configuration, but does allow for layers which do enable this. There is recognition that a single program should not hit this scenario but that app servers and similar may need to support it.
- mike_hearn 11y ago
  It's not really only app servers and other plugin systems that need this. Dependency conflicts happen routinely when building all kinds of Java apps, just by depending on useful open source libraries. This is one of the pieces of feedback I sent to the Jigsaw team and I'm glad to see it appeared in Mark's list of issues to consider. Gradle's dependency tools help, but the best it can do is either flag an error or automatically de-conflict modules by always picking the newest version. If the version isn't fully backwards compatible, you can get deadlocked.
  - aardvark179 11y ago
    I'm torn on this. On one hand the sort of multiple version support offered by OSGi can be very useful, but equally debugging and coverage tools can quickly become confused because they may not cope well with multiple classes with identical names, and that ignores the fun of conflicting native libraries. So for the first version I'd be happy to see this left to frameworks sitting above the module system, but I can appreciate other view points.

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