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.

What's the downside to OSGi?

And isn't that classloader magic?

Have you used OSGi?

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.

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.

> Guess what? Those developers will have exactly the same problems with Jigsaw modules.

And many more. Jigsaw also locks down reflection. In addition Jigsaw lacks many work arounds that OSGi has to get software working (fragments, buddy classloading, dynamic imports, optional dependencies, capabilities, …).

Honestly I have a hard time seeing any existing large code base work on Jigsaw.

Not any more. Requiring code modifications to use cross-module reflection was too painful and was dropped in the most recent Jigsaw iteration. You can reflect across module boundaries without problems now.

Even for non-exported types?

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.htm...

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.

Yeah, Jigsaw will provide the base primitives which will allow what I described to happen. But it's up to the Java ecosystem to create or update the dependency layer above it. I'm assuming Maven will, but if they don't this is an opportunity for another dependency system to replace it. I think fixing the version conflict issue is enough of a killer feature to overcome even something as entrenched as Maven. I'm hoping Maven keeps up with these changes because I really don't want to rebuild existing build systems.

Not sure about Maven, but Gradle has already introduced a "software model" feature which is meant to map almost directly to Jigsaw modules. So the idea is you'll configure the module system through the build system, and it'll generate the right Jigsaw data for you. It also handles versioning and other things Jigsaw doesn't do directly.

But will Gradle's "software model" be compatible with Java 9's? Gradle's already incompatible in that it uses Apache Groovy instead of Java 8 for build config files.

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.

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

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

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.

No, that won't work.

Modules are not allowed to export the same packages.

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

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.

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.

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.

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.

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.

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.

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.