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