Adding the fork and forkOptions got me further on the Dagger test. I also added -verbose.
I can see: [loading /modules/java.annotations.common/module-info.class] [loading /modules/java.se.ee/module-info.class] so it is finding the modules... The stack is a bit more helpful now: An annotation processor threw an uncaught exception. Consult the following stack trace for details. java.lang.NoClassDefFoundError: javax/annotation/Generated at dagger.internal.codegen.SourceFileGenerator.<clinit>(SourceFileGenerator.java:49) at dagger.internal.codegen.ComponentProcessor.initSteps(ComponentProcessor.java:103) at dagger.shaded.auto.common.BasicAnnotationProcessor.init(BasicAnnotationProcessor.java:121) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init>(jdk.compiler@9-ea /JavacProcessingEnvironment.java:674) at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next(jdk.compiler@9-ea /JavacProcessingEnvironment.java:771) at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(jdk.compiler@9-ea /JavacProcessingEnvironment.java:862) at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$2100(jdk.compiler@9-ea /JavacProcessingEnvironment.java:107) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(jdk.compiler@9-ea /JavacProcessingEnvironment.java:1184) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(jdk.compiler@9-ea /JavacProcessingEnvironment.java:1292) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(jdk.compiler@9-ea /JavaCompiler.java:1229) at com.sun.tools.javac.main.JavaCompiler.compile(jdk.compiler@9-ea /JavaCompiler.java:903) at com.sun.tools.javac.main.Main.compile(jdk.compiler@9-ea /Main.java:280) at com.sun.tools.javac.main.Main.compile(jdk.compiler@9-ea /Main.java:144) at com.sun.tools.javac.Main.compile(jdk.compiler@9-ea/Main.java:55) at com.sun.tools.javac.Main.main(jdk.compiler@9-ea/Main.java:41) Caused by: java.lang.ClassNotFoundException: javax.annotation.Generated at java.net.URLClassLoader.findClass(java.base@9-ea /URLClassLoader.java:384) at java.lang.ClassLoader.loadClass(java.base@9-ea /ClassLoader.java:486) at java.lang.ClassLoader.loadClass(java.base@9-ea /ClassLoader.java:419) ... 15 more Looks like this line is the one instigating the NoClassDefFoundError: https://github.com/google/dagger/blob/master/compiler/src/main/java/dagger/internal/codegen/SourceFileGenerator.java#L49 private static final AnnotationSpec GENERATED = AnnotationSpec.builder(Generated.class) .addMember("value", "$S", ComponentProcessor.class.getName()) .addMember("comments", "$S", GENERATED_COMMENTS) .build(); Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 5, 2016 at 8:19 AM, Stephen Felts <stephen.fe...@oracle.com> wrote: > I sometimes find tracking down JDK9 related fixes difficult. > > Obviously some are easy like PermSize on the command line. > Anything that depends on rt.jar or finding tools.jar is broken. Some > tools validate the jdk directory by looking for rt.jar. Some like jython > use it to resolve class names. > The class version number change broke anything that uses ASM - spring, > jarjar, gradle (embeds it), glassfish hk2, jersey. I temporarily coded > already all of these by pre-pending fixed classes for all of these > (properly re-packaged for each) to the classpath. > There are some changes needed in ant (although using a fork="true" works > around some of them). > Weld is broken although you can update the pom. > Jmockit has gone through many iterations of various things being broken. > 1.25 fixed some JDK9 problems but removed some API's that we depend on > heavily (1700+ references). > We are making use of an argument file on the command line and also an > argument file passed in the java via _JAVA_OPTIONS=-XX:VMOptionsFile. > Gradle is tricky because of the daemon. Also, you can't pass an argument > file to gradle because it puts the arguments in an argument file and > nesting isn't supported. So then we need to pass the arguments directly in > addition to the arguments files. > > tasks.withType(JavaCompile) { > > options.fork = true > options.forkOptions.executable = 'javac' > if (JDK9BASE != null) { // For Jake, set paths and exports > // These will be removed when the CORBA replacement is completed > options.compilerArgs << '-addmods' > options.compilerArgs << 'java.corba,jdk.rmic' > ...... > } > } > > I don't seem to be able to change the addmods option for a single module. > For example, I have the above two Java modules set globally but for one > Gradle module I need java.xml.bind and I can't just re-set it at the > individual module level to -addmods java.xml.bind. > > > > -----Original Message----- > From: Malachi de Ælfweald [mailto:malac...@gmail.com] > Sent: Tuesday, July 05, 2016 4:15 AM > To: Remi Forax > Cc: jigsaw-dev@openjdk.java.net > Subject: Re: JDK9 Modules > > Hi Remi, > > with: > compileJava { > options.compilerArgs += [ > "-addmods", "java.se.ee" > ] > } > > It still says it can not find javax/annotation/Generated I'm on build > 9-ea+123 > > > > > Malachi de Ælfweald > http://www.google.com/profiles/malachid > > On Tue, Jul 5, 2016 at 1:02 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > > ----- Mail original ----- > > > De: "Malachi de Ælfweald" <malac...@gmail.com> > > > À: jigsaw-dev@openjdk.java.net > > > Envoyé: Mardi 5 Juillet 2016 09:00:22 > > > Objet: JDK9 Modules > > > > > > While I understand the motivation behind making the system more > > > modular, > > I > > > am having a bit of a problem understanding how to use it with > > > existing > > 3rd > > > party APIs. I saw the email thread with Alan and Stephen discussing > > > how there was a need to test some of the tools. > > > > > > Over the last couple weeks, I have been testing various APIs, mostly > > within > > > Gradle. While most of them work (as would be expected by any > > > dev/user) a couple did not work with JDK9. After spending a few > > > hours trying the various suggestions (jdeps, -addmods, etc) I have > > > not yet managed to get any API to work that showed a module problem. > > > So far, my only resolution has been to downgrade to JDK8, but that > > > is obviously not the ideal > > solution. > > > > > > I'd really like to understand how to troubleshoot it and fix it so > > > that I can help others with the transition. So far, none of the > > > suggestions I have found work. > > > > > > Neo4j fails due to internal Sun classes being used: > > > cannot access class sun.nio.ch.FileChannelImpl (in module java.base) > > > because module java.base does not export sun.nio.ch to unnamed > > > module @0x6166e06f > > > > > > Dagger fails due to the @Generated: > > > NoClassDefFoundError: javax/annotation/Generated > > > > > > For the Neo4j case, I assumed I may just be out of luck with the > > > sun.* classes, however as an end-user I thought there would be some > > > way to specify that I want all modules installed. I could not > > > figure out how to do that. I tried to use jdeps to figure out what > > > to do, but it is not > > very > > > friendly with dynamically included transitive dependencies. > > > > > > For the Dagger case, I know it is accepting the '-addmods' argument, > > > because it gives an error if I use '-J-addmods'. I also know that > > > it is accepting "java.annotations.common" because if I change it to > > > javax, it gives an error. But it still can't find the class. I've > > > also tried ALL-SYSTEM and ALL-UNNAMED. > > > > > > > > > I know that eventually these modules will have to be updated to > > > include their module export definitions... but what can I do to fix > > > it. Better yet, as an end-user, what can I do to just auto-resolve > everything? > > > > > > > > > Malachi de Ælfweald > > > http://www.google.com/profiles/malachid > > > > > > > Hi Malachi, > > javax.annotation package is in a module which is not a boot module > > anymore, (because this package is defined both by the java se spec and > > the java ee spec and jigsaw doesn't allow split package) you should > > use "-addmods java.se.ee", see JEP 261 [1] (you can look for > > java.se.ee in the text) > > > > cheers, > > Rémi > > > > [1] http://openjdk.java.net/jeps/261 > > > > > > >