JPMS started as a modest project. JVM runtime is too big, lets split it into separate modules so that it is smaller. After all, other languages did it and it was not too much trouble for them.
But then Oracle decided to have a more ambitious goal. Lets create a whole new Java Platform Module System which we will expose to the outer world and nudge other developers into using it.
Years went by, the daunting revelation settled on how difficult it is to design JPMS that would work in all very broad use cases for Java. Finally, Oracle decided to get current prototype into Java 9 and make it a standard.
The prototype was a funny one. It was not able to support many valid use cases, it had a ton of yet to be implemented parts. How would one proceed with such a thing? Simple! Lets ban all the use cases that do not fit in. Brilliant.
Finally time came for the spec to be put for the EC vote. The proposed spec required every single Java library in existence to be changed just to work the same. And a great number of libraries would need to be rearchitected from scratch (pretty much anything that uses reflection). Finally, a small number of libraries would not be feasible at all anymore.
What about the vast pool of existing libraries? The main strength of Java as ecosystem is that there is a library for anything. Do you want to support some ancient protocol (SMPP?) - there is a library for that. Do you want to run your Cobol code on JVM - there is a library for that. They are libraries for old devices and protocols, that are not in active development anymore. Their authors are long gone, forgot they ever wrote them, but if you get hold of that library it will work for you.
Oracle decided to cast a blow to all that. To the main reason Java is still around. Our new JPMS requires a change to every single java library in the world. Pretty much "lets deprecate all the java code written so far". Great call!
But somehow they got EC to agree to that. EC only put forward very modest concerns about a few of the now-impossible use cases that they need. After all, it was RedHat and IBM, who complained the most. Their points were small. It would not make JPMS much better, just a tiny bit. But Oracle did not budge. They tried to power through, admitting a huge deal of ignorance along the way. Read this:
<...> we would have started by studying the internals of many existing module systems in order to identify a common set of primitives to which we would be willing to commit for the long term. That's not what we've done, however <...>
In a way, JPMS is a modern system. Not in a good way though. It is vulnerable to the kind of issues NodeJS package management system had. For instance, the module is referenced by name, and when a newer version of the module becomes available to Java runtime, it pulls it in. Much like npm does. Or the python's system. Or Ruby's. It may be just a coincidence that those suffer from bad modules being published and "breaking the internet" suddenly.
At this time, Oracle is faced with a hard choice. It can power through and get current JPMS into Java 9. Or it can do something else and try to write a module system that would be a step forward.
Fun times, indeed.