Building jar targeting multiple Java versions, including 9

[Robert Scholte]

Hi,

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.

thanks,
Robert

[1] https://issues.apache.org/jira/browse/MCOMPILER-275



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

> 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  
>> sun.tools.attach.HotSpotVirtualMachine:
>>
>> ```
>> class MyClass (in unnamed module @0x4d14b6c2) cannot access class  
>> sun.tools.attach.HotSpotVirtualMachine (in module jdk.attach) because  
>> module jdk.attach does not export sun.tools.attach 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 module-info.java 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/MyClass.java
> javac -d classes src/module-info.java
>
> 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  
> com.sun.tools.attach. It's never been documented to make direct use of  
> types in sun.tools.attach. 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/sun.tools.attach=<target>", where <target> is your module  
> name or ALL-UNNAMED if your library is on the class path.
>
> -Alan