Menu
In order to understand the categories we have:
All classes and jars within the classpath will be part of the unnamed module. But why is that what we need? Where is the advantage over automatic modules? I could "require" those damn legacy jars to make them to an automatic module. Do I not have included everything with it?
893
In Java 9 the classpath gets completely revamped with the new Jigsaw modularity system. In Java 9 a jar can be declared as a module and it will run in it's own isolated class loader, that reads class files from other similar module class loaders in an OSGI sort of way.
Since there were never any boundaries between JARs on the class path, it makes no sense to establish them now and so there's a single unnamed module for the entire class path. Within it, just like on the class path, all public classes are accessible to one another and packages can be split across JARs.
In Java 9 a jar can be declared as a module and it will run in it's own isolated class loader, that reads class files from other similar module class loaders in an OSGI sort of way. This will allow multiple versions of the same Jar to coexist in the same application if needed.
To launch a modular app, run the java command with a module path and a so-called initial module - the module that contains the main method: This will start a process called module resolution : Beginning with the initial module's name, the module system will search the module path for it.
There are at least two reasons:
--add-modules).I have no time right now to check the second but that's what the State of the Module system says:
After a module graph is resolved, therefore, an automatic module is made to read every other named module, whether automatic or explicit
Resolution works on the declared dependencies and an automatic modules declares none.
95
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
