> Are they third-party dependencies of your application, or fourth-party?
It's a mix of both > Also, what did their maintainer say when you pointed out the existence > of split packages, and how they make it difficult to use the JARs as > automatic modules? Well, I'm not sure everyone is buying importance of Java modules usage with extra headache involved. So I expect some of those to continue be just old Java8 jars unless some Java 18+ will deprecate classpath usage completely, which I doubt. > When you're faced with code that's aggressively unmodular, it seems > attractive for the JDK to come swinging to the rescue with a power-user > command-line option to tweak the environment just so. But these options > accumulate in scripts (and then get forgotten about)... In this case it's not a tweak, but similar functional parity with Maven where we could do flexible exclusions. There were lot of approaches of Classloaders filtering in Java8 cases and I don't see why we cannot have similar here. Andrejus
