Split Packages and Bootstrap Jars in Java 9

Question

It seems that in Java 9 it is not allowed to have so-called Split Packages, i.e. the same package being defined in two different modules. This causes a problem with my migration process: The (Gradle) project contains a Jar file that is called bootstrap.jar, with a structure like this:

bootstrap.jar
- com
  - example
    - Foo.class
    - Bar.class
    - Baz.class

The src directory contains a class com.example.Bar that depends on Foo as well as a module definition, for com.example. The bootstrap.jar file does not contain a module info, as it was compiled before Java 9, so it uses an automatic module called bootstrap. The problem is that now the package com.example is defined in both modules, com.example and bootstrap.

The reason there is this bootstrap.jar file, to begin with, is as follows:

The src/com/example folder actually contains Bar.java, Baz.java and another file, Foo.dyvil. The latter is written in a JVM-based programming language. So the dependency chain looks like this:

Bar.java -> Foo.dyvil -> Baz.java

During the build process, it gets compiled to Foo.class, which gets placed in a new Jar file that later replaces bootstrap.jar. The reason all these files are placed is that both the Java and Dyvil compiler cannot process the other languages files, so they require some access to the compiled classes from the previous build. So that is why there is bootstrap.jar.

Now for the actual problem: Since split packages are disallowed in Java 9, is there any way to achieve "split builds" using "bootstrap" jar files as described and used in my project? Or is there any other approach?

Answer 1

Though the long-term solution to this is resolving such packages to exist in a single module and then modularising the code.

As a temporary solution, you can make use of the option:-

--patch-module <module>=<file>(<pathsep><file>)*

as in your case

--patch-module com.example=bootstrap.jar

Do keep in mind though, the --patch-module option is intended only for testing and debugging. Its use in production settings is strongly discouraged.