Building jar targeting multiple Java versions, including 9

Robert Scholte rfscholte at
Fri Aug 26 10:49:51 UTC 2016


I'm struggling with this issue too.
I would have liked to see all the files under src/main/java, but since  
module-info cannot be compiled at the same time as the other files we need  
to do some extra things:

Possible solutions:
- Keep them all in the same folder but let Maven do 2 javac executions,  
auto-selecting the right files. I don't like this kind of magic and when  
the configuration of the maven-compiler-plugin becomes complex, there's a  
chance the magic is doing it wrong.
- Introduce an extra sourcefolder. This is by far the most clean solution  
and with good documentation we should be able to explain this.
I've created MCOMPILER-275[1] to implement this new feature.



On Fri, 26 Aug 2016 12:02:02 +0200, Alan Bateman <Alan.Bateman at>  

> On 26/08/2016 09:52, Oliver Gondža wrote:
>> I am about to stretch support of my project from java 6, 7 and 8 to  
>> version 9 as well. It does not work there out of the box as it accesses  
>> ```
>> class MyClass (in unnamed module @0x4d14b6c2) cannot access class  
>> (in module jdk.attach) because  
>> module jdk.attach does not export to unnamed module
>> @0x4d14b6c2.
>> ```
>> Before I had a chance to experiment with introducing modules to my  
>> application and declaring dependency on jdk.attach, my project refuses  
>> to compile on java 9 as soon as I add as I instruct  
>> javac to produce java 6 bytecode (-target 1.6 -source 1.6):
>> ```
>> modules are not supported in -source 1.6; use -source 9 or higher to  
>> enable modules
> You can invoke javac twice, as Uwe mentions. One starting point is:
> javac -release 6 -d classes src/p/
> javac -d classes src/
> The resulting classes should work with JDK 6+ on the class path, or as a  
> module on the module path with JDK 9. The important thing with the  
> second compilation is that you specify the same output directory as the  
> compiler access to the source or class files when compiling the module  
> declaration.
> I see multi release JARs have been mentioned. This is also something to  
> look at, assuming you end up with classes (beyond module-info) that are  
> Java release specific.
> In your mail then the class is "MyClass", I'm guessing this isn't really  
> your actual class name. If it is then keep in mind that named modules  
> require the classes to be in packages, you can't have types in the  
> unnamed package in a named module.
> On the attach API then the supported/documented API is  
> It's never been documented to make direct use of  
> types in Are you casting the VirtualMachine to a  
> HotSpotVirtualMachine and hacking into implementation? It might be best  
> to explain what you are doing. You can of temporarily break  
> encapsulation to allow the above to compile/run with `--add-exports  
> jdk.attach/<target>", where <target> is your module  
> name or ALL-UNNAMED if your library is on the class path.
> -Alan

More information about the jigsaw-dev mailing list