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.bate...@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
