Split Java Packages
The process of splitting packages has many shortcoming in the pre-JDK 9 class path mechanism, because they lead to very difficult to debug scenarios. Thanks to resolution they are completely impossible in a modular application, which is obviously good for long term maintenance.
Reliable Dependencies: This is what we really mean by reliable dependencies. The dependencies in a graph are reliable, when each module can access only one version of a package at a time.
No split packages
The guarantee of no split packages is a big deal for performance as well.
Because we know precisely which module exports which package, there is no need to scan every module in the system image and on the module path. When trying to load a class. Contrast that with how you load classes from the class path.
Reliable Dependencies: This is what we really mean by reliable dependencies. The dependencies in a graph are reliable, when each module can access only one version of a package at a time.
No split packages
The guarantee of no split packages is a big deal for performance as well.
Because we know precisely which module exports which package, there is no need to scan every module in the system image and on the module path. When trying to load a class. Contrast that with how you load classes from the class path.
Hadoop
Here is the classpath for Hadoop.
Linear Search through 110 jars
The compiler or runtime has to do a linear search through 110 jars whenever a new class is needed. Of course the implementation can speed things up by caching the classes it found, when it wasn't looking for them. But there is still a lack of unique mappings for the existing jars.
Question: How would you even find out that that is going on? (TJH) When Java was first released, no one ever envisioned how complex applications could become with each addition of a new jar. With a 110 jars there are over 12,000 possible interactions between classes in different jars. Each one starting a linear search, the class path is the ultimate in erasure. Whatever you know about the structure of your application, the class path throws it away and connects everything to everything else.
Question: How would you even find out that that is going on? (TJH) When Java was first released, no one ever envisioned how complex applications could become with each addition of a new jar. With a 110 jars there are over 12,000 possible interactions between classes in different jars. Each one starting a linear search, the class path is the ultimate in erasure. Whatever you know about the structure of your application, the class path throws it away and connects everything to everything else.
With modules you are telling resolution 1) what you know about the structure of your application (those "requires" directives) and it uses that information to provide both safety and performance at a) compile-time and b) run-time.
Split Packages in the Real World
The prohibition of split packages in modules has an impact on application design as well.
One reason that a package might have been split across jars was to allow different parts of an application to share âpackage privateâ code while allowing the parts to evolve independently. Now these jars can't be turned into modules because they would all be exporting the same package.
However, the module system has a better way to structure the application than splitting a package.