[pron]

> You can't put jmods on the module path, even though it would be easily implemented.

Yes, it could be easily implemented, although things would work nicely even without that. You make it sound as if there would have been proper build tool support if that were the case, but JARs can be easily put on the module path and still build tools don't properly support even that yet.

> When native code gets involved they are platform specific

Well, yeah. Native code is platform specific, and that's one of its main downsides and why most libraries don't (and shouldn't) use it. But when it is used, it's used for its upsides.

> At some point the JDK developers need to stop pointing the finger at build tool providers

All of the problems you mentioned could only be solved by build tools, but we're not pointing fingers in the sense that we blame build tools for things being bad. After all, modules have been very successful at allowing us to do things like virtual threads and FFM and remove things like SecurityManager. Build tools providers can have their own priorities, just as we do. But if you want to enjoy your own modules or 3rd party modules then you'll need good support by build tools.

> They could contribute patches to change these things upstream, or develop their own build system, but have never done it

Yet. There were more urgent things to work on, but maybe not for long.

[nvm0n2]

Gradle will put JARs on the module path if the app itself is a module. If JMODs were an extension to the JAR format rather than a new thing, and if there was no such thing as the module path (modules were determined by the presence of their descriptor), then nothing new would be needed in build systems and everything would just work.

[pron]

No, working with modules requires the ability to place some JARs on the classpath and some on the classpath arbitrarily. Any kind of automatic decision regarding what should be placed on the classpath and what on the module path misunderstands how modules are supposed to work. The -cp and -p flags don't and aren't supposed to differentiate between different kinds of JAR contents. If they did, you're absolutely right that the different flags wouldn't be needed -- the JDK could have looked inside the JAR and automatically say this is supposed to be a module or not; the reason they are needed is because that's not what the flags mean.

A module in Java is really a different mode of resolving classes and applying various encapsulation protections. If x.jar is a JAR file, `-cp x.jar` means "apply certain rules to the resolution and access protection of the classes in the JAR" while `-p x.jar` means "apply different rules for those same classes". In most situations both `-cp x.jar` and `-p x.jar` would work for the same x.jar, applying those different rules, regardless of whether x.jar declares module-info or not. The decision of which rules need to be applied belongs to the application, not the JAR itself; being a module or not is not something intrinsic to the JAR, it's a rule chosen by the application.

It's a little like choosing whether or not to run a program in a container. You can't look at the executable and say this should run in a container or not. The decision of whether to set up a container is up to the user when configuring their setup. module-info basically means: if the user sets up a container to run me, then these are hints to help configure the dockerfile. In an even stronger sense, a module is similar to a class loader configuration; some classes may work better with some classloader configurations than with others, but ultimately the decision on the setup is not something intrinsic to the classes but to the application that loads them, and the same goes for modules.

So having the build tool or the JDK guess which rules need to apply to which classes makes as much sense as having them guess the proper heap and GC configuration the application needs -- you can have an okayish default, but for serious work the app developer needs to say what they want. The JDK makes it very easy; build tools make it very hard.