Investigate split packages and refactor to avoid any split packages across Grails and GORM for Java 11

[graemerocher]

No description provided.

[niravassar]

RESEARCH and SUMMARY

I did some research into splity packages in the area of modularization and also did a few example applications to discover what we are working with when it comes to the Java 9 with the JPMS jogsaw project

In java 9 there is both a classpath and a module path. The module path enforces the modularization feature where packages are grouped into modules. This allows encapsulation by allowing modules to define exports, requires, uses etc in the module-info.java file. There is also mechanisms for backward compatibility with legacy java jars and code. Any packages that don't use modules are brought into an "unnamed module". This will export all its own and import every other module. For jars, if they are non moduled and placed on the module-path, they become automatic modules with a default derived name. All this is so that pre Java 9 apps can be compatible and transition incrementally to modularization.

There is however the fact that when using the modularization feature, a package name can only be used in one named module (meaning split packages will cause an error). The way around this is that you just continue to place JARs in the classpath and compilation and running works as the same as before, which will permit split packages.

LINKS

• good references
• https://techbeacon.com/legacy-developers-guide-java-9
• http://openjdk.java.net/projects/jigsaw/spec/sotms/#bridges-to-the-class-path
• https://www.baeldung.com/java-9-modularity

Examples

I did run few examples and played with how these dependencies work on the module-path vs the classpath. Wrapping up code as jars and placing them on the classpath, even given they have split packages, still works. When you place them on the module-path and you still have split packages, then you get a compile time error. I used these links below to get started:

• Split packages and automatic modules
• Split packages between Automatic modules

THOUGHTS

• I think we have to strategize on how grails 4 is going to use modularization and to what extent we could utilize the backward compatibility mechanisms in the midst of the modularizing features.
• If we re to go through all the grails-core packages and get rid of all split packages by renaming them to be distinct, how do we do this to at least programmatically identify those that are a problem. There are dozens of jars and 1000s of package names. I have some ideas but want to verify it prior.

Finding split packages

I found a way to find split packages using a gradle plugin. See example project here.

https://github.com/niravassar/java-gradle-splitpackage-plugin

[niravassar]

I am looking into how to run this plugin on a grails project to find all the collisions

[niravassar]

Java Project to find split packages

I could not use a grails app to find split packages. So i created a gradle java app and dumped all the dist jars from grails in there and generated the split package errors.

https://github.com/niravassar/java-splitpackage-grails-jars

I will upload the results here
gradle-java9c-results.txt

[graemerocher]

Thanks this is really helpful 👍