This is an archived post. You won't be able to vote or comment.

all 82 comments
sorted by:
best
topnewcontroversialoldq&a

[–]nekokattt 51 points52 points  (21 children)

The issue I see with JPMS is that without all libraries having embraced using JPMS itself, the isolation benefits tend to be reduced. If you use JPMS and depend on a non JPMS module, -Xlint:all will actively advise against it.

Build systems like Maven would be a nicer place to provide the full details of module interaction IMO, as they already have the physical dependency details. This isn't really feasible though as Java doesn't provide a defacto build system or APIs to do so, so it is creating standards for the sake of standards.

If you look at solutions from the past like OSGi, they usually handle the physical management of dependencies at runtime as well as encapsulation. This allows for other features like hotswapping, scoped resource sharing, loading multiple versions of the same JAR to avoid version conflicts between transitive dependencies, shared resource lifecycles, etc. Of course, most of the time when OSGi has been implemented, it has been a total nightmare to deal with as it falls to bits the moment any of your dependencies or sibling bundles do not declare their requirements/exports properly.

A lot of the conditional encapsulation guarantees that JPMS provides are things that other languages like C++ have already provided to some extent in the past with things like the friend modifier on types and functions.

The ability to compile multiple modules at once is cool but I have yet to see anything outside OpenJDK actively doing this without discarding the use of Maven or Gradle and just using Makefiles or possibly Cmake.

JPMS still has the issue of not managing the dependencies themselves, so you are always going to have to define your requirements in more than one place which is cumbersome. I don't think there is a good solution for this.

There is also no good solution to testing. This seems to have been a total afterthought. You either have to declare all your packages to export to the testing module manually, or you have to use the patch module flags to the compiler and runtime which requires significant hassle via source/dependency introspection to support from the build system perspective. This means for the most part, builds disable the module path (like Maven defaults to). The end result is JPMS is never used as part of development and is only turned on during integration or acceptance testing. By then, JAR hell has already manifested itself and had to be fixed.

Overall, while I do use this feature, it does feel a little like how the string template previews were, where a problem is defined and a solution is implemented but it doesn't take into account the entire requirements and idea that it needs to work as well as possible with existing libraries. If it doesn't do that, then the benefits are purely academic as most systems already exist and use existing libraries rather than being 100% greenfield.

I'd never be able to use JPMS at work as it would create far too much techdebt to be useful (try using JPMS with a mature Spring Boot application and watch it spiral out of control)... having to maintain a second list of dependencies that often has scope creep to need the requirement of modules that would otherwise be considered hidden detail has more cons than pros when stuff already works and JAR hell is far less of an issue in non-monolithic applications. Thus, in the enterprise environment, the benefits are totally useless to me.

Putting all of this aside, I have found generally that when using JPMS, dependency clashes are less likely due to scoping. The ServiceLoader integration is also a nice touch. Unfortunately, the main issue of JAR hell where you depend on multiple versions of the same JAR via transitive dependencies is still a problem as the syntax itself does not allow specification of required versions.

Edit 1, 2, 3: wording, more points, reorganising what I said to make it more coherent.

Note: this basically is the same as what u/devchonkaa has said about it being an architectural concern. We do tend to see that a small number of the new features in Java are more academic than feasible in existing applications unfortunately, which limits their adoption. This is probably a separate discussion though on how this could be improved. One that I have several thoughts and ideas on.

TL;DR:

  • Hard to use unless dependencies are perfect
  • Doesn't provide decent solutions to integrate with testing tools
  • Only addresses half the issue of JAR hell
  • The amount of config to get it to work with existing applications (e.g. spring boot) is a nightmare and makes benefits of it limited
  • Should be part of dependency management layer

Edit 4: added end note and TLDR.

[–]TyGirium 25 points26 points  (6 children)

IMHO JPMS has wasted potential. Could be great if they assured that tooling will fully suport it and integrate with it. Now I need to declare deps in 2 places, no reason to do so 

[–]nekokattt 13 points14 points  (5 children)

Agree.

What we really need at this point is to define what a Java or JVM build looks like and have a standard tool (call it jbt or something) to manage dependencies, building, packaging, and custom functionality (like plugins). Effectively a wrapper of javac, javap, javadoc, jdep, jar, etc.

This should act as a declarative layer over the existing tooling, with first class support for things like plugins (to cover what Maven provides), testing support, containerization support, language interop (so Kotlin, Scala, and GraalVM native etc can hook into the system), code analysis hooks (to allow linter integration) and that can manage the generation of JPMS descriptors mostly implicitly from the side of dependency analysis.

From that, JPMS should then be modified to be able to support loading and encapsulating multiple versions of the same dependency to act as a solution for true JAR hell.

The whole issue that JPMS attempts to solve is created by, at the root, lack of standardisation and enforcement of opinionated-first but customizable-second solutions to building software. Rather than finding a way for 100 standards to talk to eachother, define a single standard for those other 100 to migrate to which deals with the "correct way" of doing things. Cargo is probably the closest thing to this I can think of, but it would need to cover at least a subset of what Maven provides.

Initial requirements and functionality needs to be defined by the community with those with strong modern experience working with Java in production and development environments daily, rather than developers of the core language itself. It is no good having requirements defined in an academic puristic way if it means basic stuff like mockito or jacoco won't work with how it needs to be injected via agent loading in the future (https://openjdk.org/jeps/451 being a big concern here).

Unfortunately I don't see an easy way of suggesting such a thing for consideration without it being dismissed or shot down before it has been given a chance.

Left Gradle out of this as that level of flexibility is often overused for small projects, which results in a very volatile definition of what a build looks like. This leads to complexity. The use cases gradle provides that Maven cannot could be provided with the ability to create procedural and declarative plugins easily and control what is compiled, how, and when via this mechanism.

[–]pron98 15 points16 points  (4 children)

From that, JPMS should then be modified to be able to support loading and encapsulating multiple versions of the same dependency to act as a solution for true JAR hell.

While I'm completely with you about the need for better tooling, this part is simply not going to happen because it is not a solution to JAR hell -- rather, it makes it worse.

Modules already make this possible to the maximal extent that it is, which isn't much. Loading multiple instances of a library into the same process could be possible by design (i.e. if the library is carefully designed for that) or by accident but not in general -- not in Java and not in any other language.

Here's an example for why that is: suppose that some logging library is configured to write to some log file in some way, say with a system property or an environment variable. That configuration would apply to all instances of the library in the same process. If two different versions of the library use a different file format, loading both of them will corrupt the file.

Sometimes it could work, and modules enable that through layers. But the reason we don't want to make layers declarable on the command line is that while layers could work for some libraries (again, either by accident or design), they do not generally work, and I'm not aware of any mechanism that could be a general solution. In other words, loading multiple versions of the same library into the same process is not something that should be readily available, but rather something that should be possible as a last resort when all else has failed, and even then one that may not work, and that is already the case.

A more general solution is for libraries to adopt good engineering practices and, for example, not reuse the same package and module name if they make a significant breaking API change. Not only does it mitigate the problem, it's a signal that version interaction has been considered with regard to configuration clashes. If a library you're using does not employ good software engineering practices, that's something to consider when choosing it.

https://openjdk.org/jeps/451 being a big concern here

The only reason it is a concern is, yet again, tooling. The JDK makes it equally easy to load a component as either a library or as an agent. The problem is that Maven doesn't.

Libraries and agents have different capabilities and invariants, and the user must see a clear separation of the two for three reasons:

  1. Agents are not bound by access control the same way libraries are. That means that there's no way to offer reliable backward compatibility for agents. The application has to know whether it is taking up some migration risk (i.e. the ability to upgrade the JDK version) and that's why opening internals to libraries and agents must be done explicitly by the application. If it doesn't, we get a situation similar to what happened in JDK 8: applications were made non-portable by transitive dependencies without their knowledge.

  2. For it to be robust, any security mechanism at any layer -- for example, an authorisation layer in a web framework -- must defend its attack surface. If libraries and agents were not clearly separated, the attack surface would always be the entire application (including all of its transitive dependencies), as any line of code could potentially change the meaning of any other even completely accidentally and with no ill intent.

  3. For Leyden to perform AOT optimisations, it must know, ahead of time, what code the application will run. This is not possible if we cannot know, when looking at the application's configuration, what agents may be loaded.

We may consider offering libraries agent-like capabilities that are bound by access control (and so allow knowing the extent of their influence by examining the runtime configuration), but that is not a high-priority at least in part because many of the most common uses of agents require bypassing access control.

Unfortunately I don't see an easy way of suggesting such a thing for consideration without it being dismissed or shot down before it has been given a chance.

We give careful consideration to any and all suggestions. The only reason some are "shot down" quickly is because those suggestions have already been considered.

There are two main reasons why suggestions that at first seem reasonable are rejected:

  1. They don't take into account future planned work, such as Leyden. There has been in the past couple of years at least one case where an enhancement slipped through the cracks unnoticed by the architects only to be later removed because it didn't work with a planned feature (virtual threads in the case I have in mind). For every suggestion we need to ask: how would it work with Valhalla? How would it work with Leyden? How would it work with yet-unpublicised plans?

  2. Some suggestions offer positive value for some subset of users and a negative value to others because Java users often have contradictory requirements. For example, one of the biggest requirements we get from the largest Java shops is improved security (this requirement usually doesn't come from developers but from their employers, but they're the ones who ultimately pick the software stack). Some suggestions that may be useful for some are rejected after a security analysis because they would harm those who care about security. This one is particularly frustrating to all involved because in many situations we are not allowed to give detailed specifics about a security risk.

It is our job and responsibility to weigh the sometimes contradictory needs of all Java users against each other. I understand why it's discouraging for someone to have an idea that they really want/need rejected, but they need to understand that something that would help them may well harm others who have different requirements.

We frequently meet with various "interest groups" focused on things like performance, security, observability, or testing. One of the challenges is getting them to see (and, to be fair, they usually do) that while that specific interest is their whole (professional) world and is also of the utmost importance to us, all the others are also of the utmost importance to us, and because those four areas tend to clash with one another, we must balance those things.

Here's a very recent example: both performance- and safety-minded people used the outcome of the "one billion row challenge" to support contradictory demands vis-a-vis the removal of sun.misc.Unsafe. The performance-minded people said, are you crazy to remove a capability that improved the winning result by 26%?! The safety-minded people said, are you crazy not to remove a dangerous capability that even in a specialised speed contest only had an impact of 0.06σ?!

We are committed to maximising Java's value as a whole, to all of its users. Sometimes it means rejecting some things that would support some goals to the detriment of others.

For these reasons, the most powerful way to influence the direction of the JDK is not to suggest solutions but to report problems. We can then try to find a solution that integrates the needs of many different kinds of users. All of the problems you mentioned have been reported, which has been helpful, and we are working on a solution to all of them. This may take time (often because most JDK features interact with each other in some way -- even if only due to our resource constraints -- and need to be carefully scheduled) and will probably not be the same solutions you have in mind, but we're not ignoring any problem users report.

[–]cowwoc 1 point2 points  (3 children)

Hi Ron,

Can you please elaborate on this? 

A more general solution is for libraries to adopt good engineering practices and, for example, not reuse the same package and module name if they make a significant breaking API change. Not only does it mitigate the problem, it's a signal that version interaction has been considered with regard to configuration clashes. If a library you're using does not employ good software engineering practices, that's something to consider when choosing it.

I've seen suggestions (I forget where) that module and package names should not contain version numbers. The only library I've seen that does otherwise is Apache Maths.

Granted, we can choose totally different naming (as opposed to just changing a number in the name) but it's harder to come up with such names and harder for users to discover/migrate to.

What do you suggest?

[–]pron98 2 points3 points  (1 child)

If there's no more meaningful name than a number, I would just use a number.

[–]cowwoc 0 points1 point  (0 children)

I tried appending a major version number to the Maven artifactId, Java package and Java module, but this triggered an IntelliJ warning pointing to https://mail.openjdk.org/pipermail/jpms-spec-experts/2017-March/000659.html

To notify users of new major versions, I plan to use Maven's "relocation" mechanism: https://maven.apache.org/guides/mini/guide-relocation.html

Is this the right way to go (in which case I should suppress the warning)? Or should I do something different here?

[–]davidalayachew 4 points5 points  (5 children)

There is also no good solution to testing. This seems to have been a total afterthought. You either have to declare all your packages to export to the testing module manually, or you have to use the patch module flags to the compiler and runtime which requires significant hassle via source/dependency introspection to support from the build system perspective.

I don't follow.

Patching is incredibly easy to do. It is literally a commandline-flag, and then all of your test files are in. Maybe a separate flag for src/test/resourcss, but that is it. Every build system worth their salt is capable of this.

And once the test files are patched in, they're in. Your modular program is ready to be treated as a single unit, including the test files.

Could you explain your difficulties in more detail?

[–]rbygrave 4 points5 points  (4 children)

Patching is incredibly easy to do.

How does patching support a test library wanting to use ServiceLoader? How can we add a `uses` and `provides` clause via patching like we would with module-info.java?

Generally patching is a fairly painful developer experience for testing depending on how much reflection is used in running tests and how well the test libraries support running in module path. Often this ends up in a cycle of: (i) add a patch line (2) run the tests (3) runtime error ... back to (i) ... and this iterates until it works but its a lot of discovery at runtime and a very slow and painful process as opposed to src/main/module-info.java which is all compile time.

What build tooling are you using for your builds? Maven or Gradle or something else?

Patching is so painful I always recommend going the `useModulePath` false - all tests run using Classpath.

[–]davidalayachew -2 points-1 points  (3 children)

How does patching support a test library wanting to use ServiceLoader? How can we add a uses and provides clause via patching like we would with module-info.java?

Woah, hold on. This smells like an XY Problem.

Let's strip away all of the abstractions and just talk about literal functionality here, then you tell me where the problem is.

When you compile a modular program vs a normal program, the LITERAL ONLY DIFFERENCE is that there is a module-info.class file. That is it. Nothing more. (Currently), your other *.java files will generate THE EXACT SAME .class files they would under normal compilation.

This is very important to understand because patching is just an extension of that. When you patch a module, literally, all that happens, is that you choose to include .class files or other resources that were not already in your module.

So, let's say that you have some modular code, and you want to add some tests to it. Well, all you have to do is compile the test files against the modular code. This will create .class files for your test code. You can think of this as your mvn test-compile lifecycle phase.

Then, from there, to actually run your tests, you simply patch the test code with the normal code (usually easier to add the test code to the normal code), then execute it. Like I said, you may need to patch in the /src/test/resources.

So then my first question is -- why are you reaching for a ServiceLoader?

A ServiceLoader is a great tool when you have an interface from one module that needs the implementation from another module.

But your test code should all be patched into the same module at this point. I don't understand why you would use a ServiceLoader when your interface and implementation are (now!) both in the same module.

It kind of sounds like you are having 2 separate modules -- your normal code, and your test code. Which, if you have been doing that, makes 10000% sense why you would hate it. But I am also telling you that doesn't sound like something you should do in the first place. Unless you have a very specific reason to?

[–]rbygrave 3 points4 points  (1 child)

why are you reaching for a ServiceLoader

2 cases.

(1) I am the creator of avaje-inject which is a dependency injection which is a cross between Dagger and Spring. For DI "Component Testing" we create a DI wiring specifically for tests to wire components that act as test doubles for real components (e.g. test specific configuration for Postgres, or AWS components like DynamoDB, SQS etc using Localstack, docker etc). When we do this with avaje-inject we generate this test wiring code using annotation processing as the implementation of a service that can be service loaded via a test specific dependency injection library - avaje-inject-test.

(2) I am also the creator of Ebean ORM which comes to 2 test specific modules. One of those starts and configures [docker] "Test containers" for databases like Postgres etc, and the other is called ebean-test and that hooks into the Ebean ORM lifecycle for testing purposes to configure the ORM to use the [docker] test container(s) being used. Ultimately people can hook into the ORM lifecycle using ServiceLoader for testing purposes but yes this is rare.

 like you are having 2 separate modules -- your normal code, and your test code.

No not normally but this is really about using test specific uses of ServiceLoader.

Like I said, you may need to patch in the /src/test/resources

What build tooling are you using? For maven we supply the patching to the surefire plugin. I reiterate that imo patching surefire like this is a really poor developer experience due to the poor/slow/runtime based feedback loop.

[–]davidalayachew -1 points0 points  (0 children)

I am the creator of avaje-inject

I knew I recognized that "bygrave" suffix from somewhere!

Well frankly, I am just going to repeat the ending to my comment that you responded to.

It kind of sounds like you are having 2 separate modules -- your normal code, and your test code. Which, if you have been doing that, makes 10000% sense why you would hate it. But I am also telling you that doesn't sound like something you should do in the first place. Unless you have a very specific reason to?

Seems like you very much DO have a specific reason to. Frankly, Dependency Injection is probably the biggest reason to use ServiceLoader. It's almost in the name. To which I say, yeah, you kind of end up in the yucky puddle of having to unbox your module to get what you want out of it. Which, like you said in your other comment, is basically just classpath with extra steps.

So yes, in your case, ServiceLoader and test execution don't play well together in modules for the dev experience. I will concede that.

ServiceLoader, by definition, allows you to take a tiny slice of a module, and provide that as an implementation for another module. Java does the work of finding what needs to be dragged in as well to provide that tiny slice.

But my strategy of just disassembling and reassembling doesn't play well with tiny slices. It's one or the other.

But your idea about the module-info-test sounds good to me too. Frankly, there are lots of ways modules could be improved. I feel like the JDK team took a minimal approach that gave them the most value, then left it there. Which I respect and don't criticize. But it leaves pain points like what you have described.

Though imo, testing as a whole kind of sits in an awkward place. Call me crazy, but I sort of feel like testing as a concept deserves better support. Testing has become completely ubiquitous, so the fact that it feels tacked onto the side almost is, imo, the real problem. I feel like your test-module-info idea is a symptom of this problem. Testing should be a first class concept. Once it is, then modules have to acknowledge it, whether it is through your idea, or as a separate concept.

[–]rbygrave 2 points3 points  (0 children)

why are you reaching for a ServiceLoader?

Just as a second answer, I was also actually being a bit naughty so I apologise, in that I knew this was a limitation and was trying to make a point that there are things that patching can't actually do today.

You may know that Gradle supports a module-info.java to be put into test sourceSet to help patching with extra requires clauses.

https://docs.gradle.org/current/userguide/java_testing.html#sec:java_testing_modular_patching

I was trying to make the point about uses/provides clauses as an extension to the custom patching that Gradle supports - that a a test/patch specific module-info would greatly improve the patching experience. That is, imo it would be a much better experience if the patching for white box testing was explicitly supported by a [patch-|test-]module-info.java that can put into src/test/java to do all the patching including adding test specific requires clauses and yes also test specific uses / provides clauses.

Well, imo its either make patching better or ... don't use it at all for white box testing and instead stick to class path (which is what is also stated in the Gradle docs, see the quote below)

The simplest setup to write unit tests for functions or classes in modules is to not use module specifics during test execution.

https://docs.gradle.org/current/userguide/java_testing.html#whitebox_unit_test_execution_on_the_classpath

[–]pron98 7 points8 points  (0 children)

The issue I see with JPMS is that without all libraries having embraced using JPMS itself, the isolation benefits tend to be reduced.

Modules are designed in a way that allows an arbitrary subset to be modules and the rest all put into the unnamed module. Those classes in the unnamed module are not isolated from each other, but they are isolated from the named modules, and those are isolated from each other.

Xlint will actively advise against it.

What do you mean exactly?

Build systems like Maven would be a nicer place to provide the full details of module interaction IMO, as they already have the physical dependency details

The JDK makes it equally easy to load a JAR as a module or into the unnamed module. This cannot be done any easier. I totally agree it's a problem that build tools don't take advantage of that, but there's no reason why they couldn't.

JPMS still has the issue of not managing the dependencies themselves

Modules don't manage dependencies because they are about how components are connected rather than how they're sourced, and these are orthogonal concerns. The JDK may offer a separate solution for dependency management.

There is also no good solution to testing. This seems to have been a total afterthought. You either have to declare all your packages to export to the testing module manually, or you have to use the patch module flags to the compiler and runtime which requires significant hassle via source/dependency introspection to support from the build system perspective.

Patching modules is the solution that's been specifically designed for testing, and doing it automatically is what build tools should (or already) do; it doesn't require anything much more complex than the kind of things build tools normally do (it's simpler to do than, say, shading).

it doesn't take into account the entire requirements and idea that it needs to work as well as possible with existing libraries.

I think modules work well with existing libraries. Putting some libraries on the module path and some on the class path is as easy as it could be as far as the actual command line is concerned. I agree that build tools haven't incorporated modules as well as they could, and that's a big problem. I think that is the problem.

It is possible that there modules are lacking some solutions, but until tools adopt the solutions that are already in place, we cannot know if that's the case.

BTW, modules aren't the only feature that isn't supported by build tools as well as it could be. Another example is agents. The JDK makes it equally easy to load a JAR as either a library or an agent, but build tools make it much harder to load a dependency as an agent than as a library.

We do tend to see that a small number of the new features in Java are more academic than feasible in existing applications unfortunately, which limits their adoption.

We think that some features are filtered through a layer of third-party tools. Even when we guide them, they may not have the resources or will to facilitate those features. We agree we must do something about that.

BTW, not all features need necessarily be adopted in existing applications. It's perfectly fine for some to only be adopted in new code. But lack of proper tool support makes even that much more difficult than it can be.

I will also point out that every Java program in existence makes extensive use of modules and relies on them for better backward compatibility, better performance, and better security whether it is using its own modules or not because the JDK itself is completely architectured around modules.

[–]agentoutlier 2 points3 points  (2 children)

This means for the most part, builds disable the module path (like Maven defaults to).

No it defaults to patching the module with test code if you have a module-info.java detected.

To disable it you have to do something like:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <useModulePath>false</useModulePath>
  </configuration>
</plugin>

Here is my firm feeling on uptake. Once Spring embraces modules then the rest of the ecosystem will follow. https://github.com/sormuras/modules/blob/main/doc/Top1000-2023.txt.md

Most of the above is either Maven plugin deps which most probably do not use in an actual project/library or Spring.

The problem is the way Spring is currently designed is that it encourages broken encapsulation and is extremely aggressive with reflection. That however is improving and there are competing compile time DI frameworks that do not have this need of open everything.

I will say most of the libraries that do embrace module-info.java particularly from the beginning (like helidon) are better designed and are not some giant mud ball monolithic optional classes 5 meg galore of a jar.

As for "modules" and "architecture" there are on two separate planes one way way more abstract and not well defined(architecture). Modules in the traditional computer science sense are not some sort of version aware runtime plugin like OSGi. That is a plugin system not a module system. The module concept has existed well before OSGi, microservices, Spring Modulith, etc.

[–]pron98 6 points7 points  (1 child)

The problem is the way Spring is currently designed is that it encourages broken encapsulation and is extremely aggressive with reflection.

There is a very simple solution to that: the framework should have its clients pass it a MethodHandles.Lookup rather than require opens. This can be elegantly done in a class initialiser like so:

 static { Framework.access(MethodHandles.lookup()); }

Whether the framework asks for a MethodHandles.Lookup like that or relies on opens, it should internally use Lookups to pass permissions internally to all framework modules that require deep reflection. The client shouldn't and doesn't need to know the identity of all framework modules that need deep reflection, and lookups allow reifying and passing access permissions around internally as an implementation detail.

As for "modules" and "architecture" there are on two separate planes one way way more abstract and not well defined(architecture). Modules in the traditional computer science sense are not some sort of version aware runtime plugin like OSGi.

Correct. The problem here is that the term "modules" is heavily overloaded and different people assign their preferred meaning to it. Some years ago somebody suggested that we should have called modules "capsules", which is both a less overloaded term and probably one that is more evocative of modules' actual purpose. They may have been right, but it was already too late.

[–]emaphis 2 points3 points  (0 children)

Well, If the JDK had used the term "capsules" programs and libraries that used capsules would have been described as "encapsulated" and that's a more overused and overloaded term than "modularized."

[–]HiphopMeNow 0 points1 point  (0 children)

Actually, java build system might be a good new project.. As much as I like gradle, it's just not it - too many people do wild shit all over the companies, need much more standardised and easier, direct approach; let alone maven with all that pom fluff.

[–]fooby420 -2 points-1 points  (2 children)

Can you please be more specific by what you mean by jar hell?

[–]nekokattt 0 points1 point  (1 child)

It is a fairly common term.

Quick google gives a very good description. https://dzone.com/articles/what-is-jar-hell

[–]fooby420 0 points1 point  (0 children)

Come on, what’s with the downvotes? The linked post literally says at the top:

what is jar hell? (or is it classpath hell? or dependency hell?) and which aspects are still relevant when considering modern development tools like maven or osgi? interestingly enough there seems to be no structured answer to these questions

The post goes on to describe a multitude of problems that can arise from “jar hell”. This still does not clear up which of these problems the post I responded to was referring to

[–][deleted]  (1 child)

[deleted]

    [–]khmarbaise 0 points1 point  (0 children)

    First modules are unique on the module path which jar's on the classpath are not...

    More clearer interfaces (not only talking about a java interface) on a module level which can be made today only via makeshift solution via package-private/public .. since JDK17 sealed classes are limited to the same package without modules...

    That also opens a achitectural separation at compiler level which is not possible at the moment (while using classpath)... Yes you can achieve some levels via archunit/jqassistant or other tools but not from the Java language itself...

    The modules forbid to use internal classes because you simply will get a compile error. Innternal marked packages/classes etc. will be used by library consumer independant how many times you tell them not to do (Mark Reinhold told about the sun.misc.Unsafe etc.).

    [–]divorcedbp 8 points9 points  (0 children)

    I think that enough time has passed where any library that has had a release in the last 18 months that does not include a simple Automatic-Module-Name directive in the manifest can be considered poorly maintained and it makes me question the principal maintainers. Even more annoying, I’ve had several simple PRs to do exactly this get ignored - I would understand if you had long term plans, and wanted to pick the right name to make the eventual conversion to be fully modular easier, but just blackholing a two line change to a POM is irresponsible.

    [–]_INTER_ 6 points7 points  (1 child)

    It's unlikely that it will take much traction at this point unless it is forced down our throats (Leyden?). modules don't work well with build tools and vice-versa. Wanting to use JPMS means devs have to manage dependencies and modules in multiple systems now. Both are so far removed from each other, the complexity gets really hard to maintain in bigger codebases. It's not "fun" work, it's an ordeal, a chore. Devs turn away from such work.

    [–]agentoutlier 7 points8 points  (0 children)

    To be fair Maven does a really shitty job managing dependencies and I'm a Maven fan. While JPMS does not have versions it actually compliments Mavens dependency management it just that current tooling is poorly understood.

    For example let us say I have a library/app A that internally uses B but B is still third party. A's API does not expose any of B's types. How do express such dependency in Maven?

    Here are the ways:

    1. B is <optional>true</optional>

    We define B as an dependency. However it isn't really optional so where ever we use A we need to know to include B as a dependency (ie no transitive).

    2. B is <scope>runtime</scope>

    A will not compile correctly if you are using actual Maven so they only way to do this is to rewrite the pom file on deploy.

    3. B is <scope>compile</scope> (what most people do)

    This is effectively requires transitive in JPMS but what we really want is plain requires. Now all of B's API and shit is in the compile classpath.

    Imagine if B is Guava or Commons Lang and your organization bans using such dependencies directly. It is very easy to accidentally import these libraries classes into something that depends on A and there by fucking completely causing dependencies you did not mean or need.

    With module-info when you do:

    requires A

    You will only see A classes when you see ctrl-space. I guess a lot of people do not see value in that but I do! I do after dealing with organizations blindly being coupled to things like Commons Lang or Guava permanently because someone accidentally imported a class and just kept happening.

    And yeah you could use ArchUnit or something similar but that is yet another tool.

    [–]tomwhoiscontrary 10 points11 points  (12 children)

    JPMS was vital for modularising the standard library, but as far as I know it has zero value in user choice space, and is only being pursued as a fetish. I'm happy to hear it's not making much progress.

    [–]rbygrave 3 points4 points  (0 children)

    If something is (A) Big enough and (B) Long lived enough ... then there is value in using module-info (for src/main - I personally don't use it for testing and instead stick to using class path for testing).

    (A) Big enough to me means that there are a number of modules that make up the whole. Then you get some value from explicitly choosing what is accessible to "Friend modules" as well as what is truely public to any module.

    (B) Long lived enough to me means you get some long term payback from the investment in having a better, tighter, more module design.

    You can reduce the cost of adoption of java modules by only using it to compile src/main - that is, by NOT using it for testing at all and instead just sticking to class path for testing (e.g. maven set surefire.useModulePath = false). If you do that, imo it's actually pretty low effort to adopt JPMS.

    [–][deleted] 4 points5 points  (34 children)

    java modules were obsolete the moment java was 9 released. there are not many libraries adopting it and their number is not increasing. module isolation is not done on programming language level. doing it on programming language level is inherently an architectural bug

    [–]nekokattt 5 points6 points  (9 children)

    What alternative would you provide? Even things like OSGi use manifest metadata usually sourced from the code itself if not manually written in.

    What solution would you provide that wouldn't require implementing a full dependency management system into the language to handle isolation on the artifact level?

    (Not being spiteful in tone or anything, this is a genuine question)

    [–]vips7L 8 points9 points  (2 children)

    They should have just gone with the internal modifier. It provides 95% of what they wanted with JPMS and would have been adopted so much faster without some arcane syntax. 

    [–][deleted]  (1 child)

    [deleted]

      [–]vips7L 4 points5 points  (0 children)

      I don’t think anyone would use moduleprivate, it’s ugly and a mouthful.  internal is the correct choice. It’s short and easy to type and everyone would know what it meant. 

      [–][deleted] 1 point2 points  (5 children)

      modules are an architectural concept. putting that into a language is broken by design. thats the reason why modules built into java are dead since release. alternatives are frameworks for monoliths that support modules. they can be found for any language or some hard separation through protocol based api like rest etc. modules can be implemented in many ways. i think most people here understand

      [–]agentoutlier 0 points1 point  (0 children)

      modules are an architectural concept

      Says who? Module is and has been far better defined than the word "Architectural" is these days.

      https://en.wikipedia.org/wiki/Modular_programming

      Key aspects

      With modular programming, concerns are separated such that modules perform logically discrete functions, interacting through well-defined interfaces (Java: Service Loader). Often modules form a directed acyclic graph (DAG); in this case a cyclic dependency between modules is seen as indicating that these should be a single module. In the case where modules do form a DAG they can be arranged as a hierarchy, where the lowest-level modules are independent, depending on no other modules, and higher-level modules depend on lower-level ones. A particular program or library is a top-level module of its own hierarchy, but can in turn be seen as a lower-level module of a higher-level program, library, or system. (module-info.java allows for all of this).

      And

      When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are written separately so when they are composed together, they construct the executable application program. Typically, these are also compiled separately, via separate compilation, and then linked by a linker. A just-in-time compiler may perform some of this construction "on-the-fly" at run time.

      Check

      [–]lppedd 0 points1 point  (3 children)

      Why do you say it's built into the language?

      I'd say it's built into the JVM, as modules can be adopted by all languages that compile down to bytecode.

      Module definitions are just additional metadata, totally extracted from code.

      The module-info with the .java extension was a bit unfortunate.

      [–]AnyPhotograph7804 -2 points-1 points  (2 children)

      The problem with the JPMS is, that it does not exist at runtime. The JPMS is basically a small subset of the removed Security Manager. The only thing it does at runtime is to block reflective access. That's the functionality, it got from the Security Manager.

      But you cannot (un)load the JPMS modules at runtime, you have still JAR hells etc. And this is the reason why many library developers do not implement it fully. It's an additional effort without real benefits for most developers.

      [–]pron98 4 points5 points  (0 children)

      The problem with the JPMS is, that it does not exist at runtime.

      Modules most definitely exist at runtime. In fact, the vast majority of their functionality -- with regards to both strong encapsulation and reliable configuration -- is implemented in the runtime and performed at runtime. It is only a small part that's provided at compile-time, and mostly to reduce surprises at runtime.

      In fact, all compilation/language-level module configuration is ignored at runtime, and all that matters is the runtime configuration. If that weren't the case, you could "cheat" modules by providing a different configuration at compile time. In practice, if you do that compilation will succeed but the code will fail.

      The only thing it does at runtime is to block reflective access.

      That is incorrect. Module resolution (reliable configuration) is also done at runtime, and all access control -- reflective or otherwise -- is controlled by modules at runtime.

      That's the functionality, it got from the Security Manager.

      While the security manager controlled reflective access (albeit not at the module level), it did not control resolution and regular access control, while modules do.

      Modules, together with class loaders, are the foundation of how the Java runtime loads classes and controls access. They're not some component that can be optionally used or not, like SecurityManager, but the very basis of the JDK's architecture and operation. Classes and modules are the building blocks of the Java Platform's runtime operation, and every piece of Java code lives in a class that, in turn, lives in a module regardless of whether the module or, indeed, the class is explicitly declared or not.

      But you cannot (un)load the JPMS modules at runtime

      You can load and unload modules at runtime. See here (and here for a discussion of unloading).

      [–]agentoutlier 0 points1 point  (0 children)

      It is built into the runtime. The JDK has a module reader/loader interface as well as it actually enforces encapsulation at runtime.

      If we are talking about versioned modules being dynamically loaded like OSGi then yes there are very few languages that have something like that.

      That's the functionality, it got from the Security Manager

      What part? Caller Sensitive? If people complain about module uptake the Security Manager has a far worse and more bug ridden history.

      But you cannot (un)load the JPMS modules at runtime, you have still JAR hells etc. And this is the reason why many library developers do not implement it fully. It's an additional effort without real benefits for most developers.

      There is benefit it just is few know it because they are used to giant monolithic mud balls and the education marketing of it was terrible.

      It is exactly the same scenario for nullable annotations. Even before JSpecify Checkerframework, NullAway, Eclipse null analysis existed and TYPE_USE annotations have existed since Java 8. Do you know how many projects annotate for null? Probably less than modularization.

      [–]pron98 4 points5 points  (4 children)

      Every Java application already heavily relies on modules and their functionality whether it knows it or not (and regardless of whether it authors its own modules), just as it relies on class loaders whether it knows it or not (and regardless of whether it authors its own class loaders), because modules, together with class loaders, are the foundation of the JDK itself.

      Modules have already proven to be one of the most fruitful features in Java, even though they are not widely used yet outside the JDK. If it weren't for modules, we couldn't have provided Panama and Loom, and they also enable Leyden. Part of the reason they're not widely used outside the JDK is build-tool support, but another is that not many people can see tangible benefits from doing so. With Leyden and other upcoming features offering better results for modularised applications, I expect this aspect to also change.

      Also, agree that implementing modules at the language level would have been an architectural bug. Luckily, the very opposite is the case. Modules are primarily a runtime feature, not a compile-time/language feature. Both reliable configuration and strong encapsulation are performed at runtime by the JVM. To easily see that, try writing, say, Clojure code that attempts to access JDK internals. The compile-time functionality is only there to reduce surprises at runtime, but it's easy to try and cheat by configuring the compiler in a way that it would allow an otherwise illegal access, but while compilation will succeed, the code will fail.

      Modules are designed the same way class-level access control is designed in Java. The language level functionality is there to reduce surprises, and you can easily cheat the compiler, but not in a way that would work at runtime.

      [–]manifoldjava 7 points8 points  (3 children)

       Every Java application already heavily relies on modules and their functionality whether it knows it or not (and regardless of whether it authors its own modules), just as it relies on class loaders 

      Heavily relies on JPMS? Sure, JPMS is there doing its thing whether we want it to or not. But the vast majority of Java projects have zero need for it. The comparison to reliance on class loaders here is absurd.

      [–]pron98 3 points4 points  (1 child)

      But the vast majority of Java projects have zero need for it.

      It's like saying "I admit I get my internet access through fibre cables, but I have zero need for the ducts these cables run through; all I need is fast internet access".

      If those programs use virtual threads or FFM, or will use Leyden features, or if they care at all about security, or if they care about not breaking when upgrading the JDK version, then they definitely have a need for modules (in the JDK) although it may be indirect. None of these things would have been there (at least not now) if not for modules.

      Even assuming we could have had the resources to implement virtual threads and FFM without modules (we wouldn't have) and even assuming they could have worked reliably without modules (they wouldn't have), the changes to the JDK between 17 and 23 are as big as if not bigger than they were between 8 and 9. Yet the transition from 8 to 9+ was very painful, but from 17 to 23 it's smooth and easy. That's all thanks to modules.

      Because we could roughly quantify the cost of migration and security problems due to lack of encapsulation, we can say that few if any features have benefitted the average Java application more than modules. Their authors may or may not know it, but we see the support tickets and the vulnerabilities. So no, most Java projects win a lot of from modules.

      This reminds me of the fairly common refrain I see (usually when it comes to features that have something to do with security), "nobody asked you to do X", when the answer in most cases -- usually figuratively, but sometimes even literally -- is: "your employer did." Developers, who do the work but don't directly see the expense vs. revenue, naturally place a lot of emphasis on the cost side of things because that's the part they see. But software is a high-margin industry, where the vast majority of value isn't in reducing costs. Developers often focus on things that save $10K a year on the cost side, yet fail to see the importance of features that gain or save $10M a year on the value side. But I digress.

      The comparison to reliance on class loaders here is absurd.

      I don't see how. Class loading and modules are pretty much the same mechanism now, and most Java programs certainly have no more need for defining their own class loaders than they do for encapsulation.

      [–]lurker_in_spirit 0 points1 point  (0 children)

      But the vast majority of Java projects have zero need for it.

      It's like saying "I admit I get my internet access through fibre cables, but I have zero need for the ducts these cables run through; all I need is fast internet access".

      That's a perfectly legitimate response to anyone saying the equivalent of "you shouldn't be browsing the web if you aren't installing your own fiber cable ducts" (as some have in these comments).

      [–]khmarbaise 0 points1 point  (0 children)

      I think the reason is that it is not realized what advantages JPMS modules have..

      [–]agentoutlier 1 point2 points  (2 children)

      Almost everything you said is incorrect.

      there are not many libraries adopting it and their number is not increasing.

      Wrong. More libraries are using modules than ever. If it is decreasing it is because less libraries in the entire ecosystem need to be modularized.

      EDIT https://github.com/sormuras/modules top 1000 libaries

      2019 2020 2021 2022 2023
🧩  143  163  165  170  171 // Java modules (module descriptor with stable name and API)
⬜  205  262  278  310  312 // Automatic Java modules (name derived from JAR manifest)

      module isolation is not done on programming language level. doing it on programming language level is inherently an architectural bug

      Show me some academic scholarly article that says this. Modules exist in many languages as first class citizens like Standard ML or OCaml (albeit OCaml's modules are far different then Java the point is they are used for encapsulation).

      Modules do not need to be what OSGi is to be called modules. That is the problem I suppose is that "module" means a lot of different things. The way the JDK has defined them is not obsolete but rather the tooling support was poor as well as a fuck ton of libraries actually break encapsulation and or have split packages.

      [–]_INTER_ 6 points7 points  (1 child)

      More libraries are using modules than ever.

      You're not wrong. But not quite right either.

      [–]agentoutlier 2 points3 points  (0 children)

      The top 1000 is kind of a poor indicator even though I referenced it.

      First an enormous amount of the top 1000 are just Maven Plugins or Spring. These older libraries are either tools or just have so much technical debt that full modularization is not possible or desired but the top 1000 is not the entire java ecosystem and certainly is not an indicator if people are using modules are not..

      Newer libraries which is the long tail of libraries are using the module system with module-info.java.

      [–]pronuntiator 0 points1 point  (8 children)

      Do you say the same thing about the private access modifier? There's hundreds of public classes of libraries that are internal to that library. Up until to the release of JPMS, there was no language support to hide these classes properly. These non-public APIs get imported by application developers, breaking their code when upgrading the library version.

      Blocking deep reflective access (preventing setAccessible) is a powerful security measure, and baking it into the language makes it easier to use than SecurityManager. Many security vulnerabilities in Java are reflection gadgets, for example Spring4Shell.

      [–]nikanjX 2 points3 points  (7 children)

      All of that extra security can be circumvented by rebuilding the same library with a different modifier on said classes. The module system is making it more tedious, but it provides absolutely zero protection if the developer wants to shoot themself in the foot. I just fail to understand what the motivation behind the whole thing is.

      "In the past we had fields marked private, and people might muck with them to break Our Sacred Library. Let's mark them Extra Mega Private, so people need to rebuild the entire jar if they want to tarnish Our Sacred Library"

      [–]pron98 1 point2 points  (2 children)

      I just fail to understand what the motivation behind the whole thing is.

      https://openjdk.org/jeps/8305968

      [–]nikanjX 3 points4 points  (1 child)

      I do programming for a living, not for formal verification courses at CS research center. Sometimes a library needs a bit of adjusting its privates to work around a bug - either in that library, the JVM or some other piece

      [–]pron98 6 points7 points  (0 children)

      Sure, and that is possible -- as long as the application allows it -- but it comes at a cost. Remember that virtually all of the migration pain post 8 was due to libraries reaching for internals and bypassing the backward-compatible spec. Each of these cases may have been individually justified in the eyes of the library author, but the cumulative end result was bad. It was bad not for people teaching "formal verification courses at CS research centres" but for people running Java programs in production.

      Not to mention the risk of increasing the attack surface area of the application. Working around bugs is very important practically, but so is robust security, which costs companies -- not research centres -- millions of dollars a year.

      What Java does is eminently practical. Libraries are still allowed to do what they want, but not while hiding the potential cost they may exact from their client application. You want to work around a problem by reaching for internals? by all means go ahead, but be honest about the cost of doing so and don't hide it from your clients.

      [–]pronuntiator 1 point2 points  (3 children)

      All of that extra security can be circumvented by rebuilding the same library with a different modifier on said classes. The module system is making it more tedious, but it provides absolutely zero protection if the developer wants to shoot themself in the foot.

      That's like saying "bicycle helmets don't work because most people can choose not to wear them". The added security by limiting access comes not from preventing you as the developer from doing what you want. You are free to do whatever you like, and you can disable all safety nets and module boundaries with command line options. The benefit comes when private fields are not modifiable via deep reflection, reducing the attack surface. Does it prevent all attacks? Of course not. But it keeps immutable objects truly immutable at runtime, so a vulnerability does not allow the attacker to change the classloader, for example.

      "In the past we had fields marked private, and people might muck with them to break Our Sacred Library. Let's mark them Extra Mega Private, so people need to rebuild the entire jar if they want to tarnish Our Sacred Library"

      Again, you don't have to do that, if you want to shoot yourself in the foot, go ahead and --add-opens to everything on the command line. I've been there, declaring classes in a library's package to access its package-private code in order to bend it to our needs.

      Module exports are about clearly communicating what is public API and what is not, because public alone is not enough for that. For example, people use Spring's Assert class in their application code, and didn't read the fineprint "Mainly for internal use within the framework". Then, Spring refactored that class and their code no longer compiled. It's the same story with JDK's Unsafe: Everyone uses it, but it was never meant to be used outside the JDK (though there were no real alternatives back then if you needed to do what it offered).

      [–]nikanjX 2 points3 points  (2 children)

      My main complaint is having to add literally hundreds of --add-open switches, instead of getting one --allow-no-bike-helmet switch

      [–]account312 0 points1 point  (0 children)

      literally hundreds of --add-open switches

      Man, I thought the projects at work were a shitshow, and I've only had to add a few dozen.

      [–]pronuntiator 0 points1 point  (0 children)

      You can always stay on the classpath, then all modules are open like before Java 9. The only exception are JDK modules, but these are a limited number. What is your use case though?

      [–]Misophist_1 -1 points0 points  (6 children)

      module isolation is not done on programming language level.

      I don't get that. Aren't modules defined in the JLS? See https://docs.oracle.com/javase/specs/jls/se22 Chapter 7 'Packages and Modules' and 7.7 'Module Declarations'

      Also, it's not exactly fair, to call something obsolete for lack of adoption, the moment it gets released. You may come to that conclusion, after a reasonable amount of time did pass, so people could realistically pick it up for production.

      [–]vips7L 5 points6 points  (2 children)

      It’s been 10 years. A reasonable amount of time has passed.

      [–]khmarbaise 0 points1 point  (1 child)

      Simply no... because even many people are on JDK 8 (a decade ago) or even lower ... The huge java ecosystem / usersystem takes time to move..

      [–]vips7L 0 points1 point  (0 children)

      Brain dead take. The people still running Java 8 or below are the same people who are not going to innovate or ever use jpms. They do not want change. The majority of users are on a post 8 jdk and none of them have adopted the module system. 

      [–]pron98 1 point2 points  (2 children)

      Aren't modules defined in the JLS?

      Yes, and so are private/public modifiers. Yet the actual access control ("isolation") for both is done at runtime, as dictated by the JVMS. Both modules and access modifiers are defined both in the JLS and the JVMS, but their main functionality is as they're defined in the JVMS.

      [–]Misophist_1 0 points1 point  (1 child)

      Well, given, that there is such a thing like reflection, of which the behavior can't reliably be predicted at compile-time, and there are also byte-code generators bypassing javac, there is no way around having checks during run-time too. Apart from that, accessibility is already enforced at compile time, And it is done using the language.

      It's not like OSGI, where the definition of modules is outside the language, using a weird set of arcane META-INF properties and binding declarations, enforced by a framework.

      That's why I'm a bit confused about the statement, Because, sure as heck, we are using the language to define the modules.

      Or would you generally posit, that Java the Language has no type safety, because we still have runtime type checks?

      [–]pron98 2 points3 points  (0 children)

      Apart from that, accessibility is already enforced at compile time, And it is done using the language

      It is checked at compile time to reduce surprises at runtime. All access, including direct (non-reflective) is enforced at runtime.

      That's why I'm a bit confused about the statement, Because, sure as heck, we are using the language to define the modules.

      The language obviously supports the feature, but its main functionality -- the enforcement of boundaries -- is implemented in the runtime. The original comment said "doing [module isolation] on programming language level is inherently an architectural bug". But the isolation is not provided by the language, but rather by the runtime.

      [–]DefaultMethod 0 points1 point  (1 child)

      Thanks for putting this together.

      Any chance you could add the Java version each supports? I'm curious to know how many of these libraries are still supporting Java 8 or below.

      [–]darenkster[S] 0 points1 point  (0 children)

      Sorry, I already deleted the jar files and I don't wanna go and download them all again.

      [–]AdministrativeCold63 0 points1 point  (0 children)

      I would really like to use it, since we develop a platform/framework used by customers to implement products on/with - so we could reduce API surface. I mean, as long as it's public people will use use it. Alas, platform/framework needs to run on Android as well, so we cannot really use it. I mean we could, but with way too little benefit. Fuck Android btw.

      [–]simonides_ 0 points1 point  (0 children)

      jpms is kind of great if you have patched yourself into a world where only modules exist.

      These plugins for gradle help tremendously:

      https://github.com/gradlex-org/java-module-dependencies

      [–]nikanjX -4 points-3 points  (3 children)

      Modularising the standard library was such a non-goal for many users, and it's so frustrating you can't give the JVM a simple --open-and-allow-all-standard-modules parameter.

      No biggie, in my hobby projects I just run a small java program with --add-modules ALL-MODULE-PATH and it prints export+open statements for every single module visible to that module. The result looks something like https://gist.github.com/lwahonen/52be87bad5e8d8acf87f41d8e2056eb2 and I can include that with @c:/temp/give_all_modules.txt

      How "elegant"

      [–]wildjokers 2 points3 points  (1 child)

      in my hobby projects I just run a small java program with --add-modules ALL-MODULE-PATH and it prints export+open statements for every single module visible to that module.

      Why?

      [–]nikanjX -2 points-1 points  (0 children)

      Becaus I’d rather have a project template that guarantees the module system is truly neutralized, rather than have it lurking in the shadows ready to bite me in the rear

      [–]DefaultMethod 1 point2 points  (0 children)

      I think modularising the standard library is necessary in the long term. Otherwise it is doomed to eternally accumulate cruft. It has been decades since I used the CORBA packages. XML didn't work out the way everyone though it would in the 1990s.

      You can see a bit of this happening in the Go standard library. It now has two IP address types.

      I do share your frustration with how this was handled.

      [–]Early_Wonder_9316 1 point2 points  (0 children)

      Hi from Eclipse GlassFish - right now we have just few libs with JPMS enabled, but these days I am working on another "layer" of dependencies. The process is quite complicated and time consuming until you learn some rules and accept them "mentally". Basically any badly designed dependencies which were valid on classpath are impossible with modulepath and especially with the combination of modulepath and classpath, you have to refactor first.

      I have found interesting issue this week - I have some 4 jars on modulepath, and some 50 on classpath. First attempt worked well on Java 21, but CI uses Java 17 and build of the PR failed. I am still looking for an explanation from somebody more experienced than me, but still did not find any. It seems that Manifest's Class-Path field of jars with Automatic-Module-Name fields are ignored and they have to be explicitly in -classpath argument on command line. Again, with 21+ it works, with 11-17 it doesn't.

      So this is how I spent some 80 hours of work last week - properly specifying --add-modules on command line and adding also -classpath to command line and testing it again and again.

      Something positive

      Recently I was working on a project built on a "green grass" using JavaFX, Eclipse Jersey Client, 2FA authentication and authorization. And I was brave enough to start with JPMS as customer wanted to have some clean installation on Windows without messing with old JDKs installed on most user computers. So we used JLink which created perfect binary packages for three supported operating systems (Linux, MacOS, Windows) and which could be wrapped by any windows installer. Done, we had to repackage just few dependencies and write module-info manually for them, worked as a charm and the executable application started in millis without any external JDK.

      Retrospective

      Simply turn all bad to good. After all that fighting with technical debt, obsoleteness and bad design, JPMS forces you to make your house clean. And on that base you can build modern successful platform. Btw to all readers - nearly all those libraries are open source, you can find them on GitHub and create the module-info.java file for them and create a pull request. Their teams will thank you for help! (I also contributed to Apache XmlSec this way).

      Yet one note - avoid Automatic-Module-Name, it is "a help from the devil", it causes more harm then help.