I do wonder if the best thing for Java's long term health would be to remove the Java module system from application code (keeping it for the JDK). Its been a huge time sink for me with absolutely no benefits. Any thoughts?

Remove packages, too! They only produce bad numbers in static code analyzer runs. While you're at it, visibility modifiers are also an absolute time sink. (...) I'd vote for a different solution: provide a kill switch for the class-path. Modules all-in or nothing.

A kill switch the other way around would be more useful. ie. to enforce that no parts of the module system are used

The module system is part of Java SE API in the java.base module.

Doesn't mean it can't be deprecated for removal and then removed.

It just means that a kill switch for it would be as absurd as a kill switch for the java.lang.ref package or the java.lang.ClassLoader API, for example.

Some parts of JDK now heavily dependent on modules. E. g. due to bootstrap issues, java.base module doesn't use indified string concatenation while other modules use it. If you remove modules you'll need to recompile all other modules to turn off this optimization there as well.

So if you want it to be a switch you won't have this optimization in JDK anymore, even if the switch is turned off. Probably there are more similar examples.

The "kill switch" was something that could be added to Maven. It wouldn't really work as a JDK option without a lot of effort.

Removing package will produce only one thing, developers moving from 24-27 inch monitors to 49 inch and above. I work on project like that with 20 inch monitors :(

Then I would use a different language.

As should surprise no one, this was given serious consideration. Among other reasons, it was clear that if went this way, folks like you (maybe even you!) would now be complaining that "we kept the goodies for ourselves and ignored the needs of applications." Damned either way!

It'd be easier to open the cookie jar in that case, rather than asking everyone around the block ot buy a box of 'em though. :)

Not necessarily. The cookie jar we would have gotten were we not to include applications in the story from the beginning might not have been big enough to share.

Weigh the time wasted for this task versus all the time wasted shading package names over the years. Which is the bigger waste of time?

The Java module system doesn't solve the problem shading is used for.

+1 for Stephens point

I’d argue that it definitely saves time pin pointing the problems that shading solves. Your mileage may vary.

And how does pinpointing it help without a solution?

At the time, I would have been arguing for it to be open to applications. The question is whether it is *now* applicable to reconsider the decision. Its above serialization in terms of pain IMO.

What do you mean by "open to applications"?

Able to be used by applications. ie. I'm suggesting removing the ability to write module-info.java

What still might help is publicly acknowledging that it’s been designed with carefully crafted scope, but applications being a different thing so that people avoid wrestling with it for it to do things it wasn’t built for.

What I found suprising is that the module system didn't get much perceivable attention at all after Java 9. Right now, open issues like conflicting private packages, or no true support for versions, attribute to slow adoption outside of the JDK IMHO.

What set adoption back multiple years is the decision that modules-info declarations should end up as a *.class file in the jar alone. Adoption can only happen after every third-party tool involved in the build process has been fixed, which will take a long time.

That's OK, we think on a long time horizon and are in it for the long haul. Those who say "it's obviously a failure because adoption is not yet 100%" are hilariously misguided about what is reasonable for such an adoption cycle. Took nearly 10y for generics to reach mainstream...

I agree. Although I have not had the chance to use it a lot yet I think it is incredibly useful for application code.

True. Except I keep hitting broken jars on Maven Central for popular artefacts; which makes it clear nobody ever put them on the module path. Fun fact: Jenkins fails silently (build green) if it detects a "JVM crash", which in turn is the JVM failing to run due to module errors.

That sounds like a bug in, well, Jenkins, more than anything else.

It's a good representation of the state of Java modules in the wild: Largely untested and usually broken in trivial ways that should have been obvious on first usage. Except that I have hit far too many issues where it appears I'm the first person on this planet to try it.

Or ... your colleagues could stop publishing broken artefacts. :-)

Yeah, but also I don't think that the decision to compile module-info to a class file set adoption back by multiple years on top of how long it would have taken had the representation been an ASCII file. Build tool support would have been required for mass adoption even then.

Then maybe you are just a bit misinformed about the problems this caused in practice. An ASCII file wouldn't have broken pretty much every existing third-party analysis/check/coverage/scanning/... tool in existence. I say pretty much, but in the codebase I work on – 100% broke.

> we think on a long time horizon IntStream, LongStream, DoubleStream and 90% of the contents in java.util.function disagree with you. > "it's obviously a failure because adoption is not yet 100%" Nice strawman, but who claimed that?

s/took 10 years for generics to reach mainstream/took 10 years for Java developers (more likely probably their enterprise managers) to stop being little babies and join the rest of the world in 1980s tech.

why this aggression? what value does it bring to the discussion, or to anything?

It probably expresses a general fatigue of the attitude exuded from current Java designers. I mean, C# designers demonstrate fairly well that it's possible to work on a language without being obnoxiously arrogant and self-absorbed about it.

I know it might not be popular but so far my experience with it was ok. What bugs me most is that I need a more powerful service story

I think the JPMS may be more important for library writers than for application developers.

Nope. Still applicable:

Imagine a new project using only the standard library. Shouldn't such a project enjoy the benefits of strong encapsulation, module system, and tailored runtime images?

And a year down the line the team decides to depend on some open source libraries but boom, they're can't b/c they are not modules. Java modules require a willingness for the whole community to adopt them. That desire isn't there as there are no benefits to library authors.

Yes, developers of such a project need to be mindful of that and acknowledge the risks. Personally, I would use modules in this scenario.

There are benefits, but one has to accept that going modular comes with a set of constraints on how you compose your software. The benefits are real, but most devs just don’t want to bother with thinking of how they manage their dependencies.

I agree that the current situation is quite horrible. For example all google cloud libraries aren't modular because grpc is not. This means you cannot use any GCP service in a modular Java 11 app without major hacks. But I think Google and other libraries will fix it eventually.

OSGi applications face a similar challenge. It is a problem, indeed.

For standalone applications, developed by a single team, I agree, the benefits are limited/questionable. For app servers/multi-application runtimes, which used to implement their own module systems, they are great. For modular multiteam monoliths they are great as well.

Can you wrap an existing un-modular library to make it a java module, like you can with OSGi?

The JMPS experiment leads me to a pessimistic conclusion: core constructions cannot be changed in large systems with many independent actors.

Funnily enough the change inside the JDK has been pretty succesful. Its a closed world so ecosystem problems don't apply to the same degree. Java modules could have been JDK-only with a simple config to select which JDK modules an application needs.