Building jar targeting multiple Java versions, including 9
rfscholte at apache.org
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:
- 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 to implement this new feature.
On Fri, 26 Aug 2016 12:02:02 +0200, Alan Bateman <Alan.Bateman at oracle.com>
> 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
>> sun.tools.attach.HotSpotVirtualMachine (in module jdk.attach) because
>> module jdk.attach does not export sun.tools.attach to unnamed module
>> 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
> 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.
More information about the jigsaw-dev