Yes, the JAR file Specification specifies what should happen if you put a non-modular jar file on the module path.
But that does not make it a good idea.
Non-modular jar files are often not JPMS ready.
They might have split-packages.
They might use things that cannot work if they are on the module path.
They might have a name with an illegal identifier that makes it impossible to derive a module name from the jar name.
The module name changes if you rename the jar file.
The module name changes if later the author of that library decides to make it a module and so the module name used in consumer module info files is wrong and cannot be used with the newer version of the library, …
There is just so much shenenigans and non-determinism if you put non-modular jars on the module path, that the Gradle guys wisely decided to not put non-modular jars on the module path, but at most such that declare an automatic module name in the manifest which should be a sign that the library author at least thought about it and at least made it JPMS compatible.
But as always Gradle just provides sane defaults and gives you the flexibility to easily do whatever you want, so if you really want to put those files on the module path for your project, then just configure your build however you like it. ![]()