I still remember that Java started as a toy language. And for all its security features and incremental improvements to JVM byte codes over the years, it still looks like a toy.
The classloader is the roller skate and the zillions of interoperating jars are the elephant. For the most part, the elephant stays up and continues blasting down that hill.
I used to think the scene was funny, but now I'm uncertain. Only through tools like Gradle and Maven have we papered over the inadequacies of the classloader system and gotten some control of it.
I had hopes that jigsaw would give the elephant an option of a little car to drive or at least a second skate to aid with balance. But safety trumps all, and such a huge breaking change should be avoided if we can.
Tools like Maven don't solve anything related to classloading in my book. All they do is make it (a lot) easier to figure out dependencies. Judging by the "no"-votes, I doubt Jigsaw would have made that much easier.
As for the Java ecosystem, it seems to be doing better than ever. Can you elaborate on why you think the roller skate is squeaky and about to topple?
Maybe 'topple' is taking things a bit too far since Java works far more often than it doesn't. How about 'teetering'?
But the roller skate is most definitely squeaky, and that's mainly because of the lack of help and organization that the built-in java systems give. I can reference two incompatible versions of libraries and the classloader will blithely load from both of them. You can claim "pilot error", but I reply that it's 2017 and we have huge memories and processors that we aren't using effectively to abstract the problem.
Why are we allowed to slam together these huge, sloppy code edifices atop a system that otherwise puts so much focus on security and safety?
Along with the standard "jar hell" arguments, I've got problems mixing cantankerous legacy spring and pre-spring era jars with post Java 8, CDI, JavaEE, etc jars. I need to containerize/componentize these assets and keep them separate from one another because they don't play nice nice with each other. Sure, I can roll my own JarClassLoaders and build a separation between groups of jars by-hand, but I never would because I want the computer to do that work for me - hence "modules".
In my opinion, if tools like Maven don't solve anything related to classloading in your book, then you are either:
1) off in your own corner rolling classpaths by hand and checking your .jar files into Git, or
2) you aren't working effectively at-scale on large software projects with groups of other people
In my case, Gradle was a revelation - it is a Groovy DSL veneer over Ant and Ivy, and it makes rolling custom classloaders extremely pleasant. Maven is very unpleasant because of its declarative XML language, but the Maven artifact coordinate scheme was a brillant stroke. I'm happy the Gradle folks were so successful in melding the platform compatibility tools of Ant, the artifacts of Maven, and the expressiveness of Groovy into a build system that even a dummy like me can grok and use effectively.
Maven was intended to be configured via a GUI. If you want to configure it directly, try Polyglot Maven at https://github.com/takari/polyglot-maven which is a very light wrapper around Maven enabling you to use many other languages instead, e.g. Scala, Clojure, and Ruby as well as Apache Groovy.
The Gradle people marketed their product by slagging the XML which was never intended to be directly manipulated by humans. If you really want to use Gradle (and get a coffee whenever it builds something), it also lets you use Kotlin for writing build files.