With:
export _JAVA_OPTIONS="-Djdk.launcher.addmods=ALL-SYSTEM
-Djdk.launcher.addexports.0=java.base/sun.nio.ch=ALL-UNNAMED"

no GRADLE_OPTIONS
no options.compilerArgs in build.gradle

1. The dagger project compiles and runs
2. The neo4j project compiles and runs
3. a JDK8 project still compiles and run





Malachi de Ælfweald
http://www.google.com/profiles/malachid

On Tue, Jul 5, 2016 at 2:07 PM, Stephen Felts <stephen.fe...@oracle.com>
wrote:

> That option is overkill.  It includes all modules.  Instead of using 
> ALL-SYSTEM,
> add just the modules that you need comma separated or java.se.ee.
>
>
>
>
>
> *From:* Malachi de Ælfweald [mailto:malac...@gmail.com]
> *Sent:* Tuesday, July 05, 2016 5:00 PM
>
> *To:* Stephen Felts
> *Cc:* Remi Forax; jigsaw-dev@openjdk.java.net
> *Subject:* Re: JDK9 Modules
>
>
>
> oh lol! I thought you were just italicizing! ;)
>
> That seemed to fix the Dagger one.
>
> Now let me try to back off of all the changes and figure out what the
> minimal configuration is.
>
>
>
>
> Malachi de Ælfweald
> http://www.google.com/profiles/malachid
>
>
>
> On Tue, Jul 5, 2016 at 1:41 PM, Stephen Felts <stephen.fe...@oracle.com>
> wrote:
>
> Well you need the leading underscore.
>
>
>
> *From:* Malachi de Ælfweald [mailto:malac...@gmail.com]
> *Sent:* Tuesday, July 05, 2016 4:36 PM
>
>
> *To:* Stephen Felts
> *Cc:* Remi Forax; jigsaw-dev@openjdk.java.net
> *Subject:* Re: JDK9 Modules
>
>
>
> adding that (without the leading underscore) I still get:
> NoClassDefFoundError: javax/annotation/Generated
>
>
>
>
> Malachi de Ælfweald
> http://www.google.com/profiles/malachid
>
>
>
> On Tue, Jul 5, 2016 at 12:58 PM, Stephen Felts <stephen.fe...@oracle.com>
> wrote:
>
> Try running with
>
>
>
> export _*JAVA*_OPTIONS=”-Djdk.launcher.addmods=ALL-SYSTEM”
>
>
>
>
>
>
>
> *From:* Malachi de Ælfweald [mailto:malac...@gmail.com]
> *Sent:* Tuesday, July 05, 2016 3:29 PM
>
>
> *To:* Stephen Felts
> *Cc:* Remi Forax; jigsaw-dev@openjdk.java.net
> *Subject:* Re: JDK9 Modules
>
>
>
> That's a very useful command. Thanks for that.
>
> I fixed it to add the 's'. I also tried it without that module.
>
>
> I had to remove -verbose from the jdk9args due to
> https://discuss.gradle.org/t/cannot-run-build-with-jvm-argument-verbose-class/17734
>
>
> 'clean' works with -verbose removed from jdk9args
>
>
> 'build' still says `NoClassDefFoundError: javax/annotation/Generated`
>
> ​
> That is despite the logs showing​:
> 12:24:13.294 [ERROR] [system.err] [loading
> /modules/java.annotations.common/module-info.class]
> 12:24:13.298 [ERROR] [system.err] [loading /modules/
> java.se.ee/module-info.class]
>
>
>
> ​Removing -verbose from the build.gradle didn't make a difference.
> ​
>
>
>
>
>
>
>
>
> Malachi de Ælfweald
> http://www.google.com/profiles/malachid
>
>
>
> On Tue, Jul 5, 2016 at 11:41 AM, Stephen Felts <stephen.fe...@oracle.com>
> wrote:
>
> Remove -addmods java.annotation.common
>
> Or change it to java.annotations.common
>
>
>
> You should get use to using
>
> jimage list --dir=. $JAVA_HOME/lib/modules > t
>
> textedit t
>
>
>
>
>
> *From:* Malachi de Ælfweald [mailto:malac...@gmail.com]
> *Sent:* Tuesday, July 05, 2016 2:34 PM
>
>
> *To:* Stephen Felts
> *Cc:* Remi Forax; jigsaw-dev@openjdk.java.net
> *Subject:* Re: JDK9 Modules
>
>
>
> Hi Stephen,
>
> Here's the result of that change:
>
>
>
> I tried this:
> export GRADLE_OPTS="@/home/malachi/work/private/sandbox2/jdk9args
> -Xmx2048m
> -Dorg.gradle.jvmargs=\"@/home/malachi/work/private/sandbox2/jdk9args
> -Xmx2048m\""
> with:
> -addmods java.se.ee -addmods java.annotation.common -verbose
>
> I should mention that I am using Gradle 3.0-milestone-2 and my
> ~/gradle.properties is already set to:
>
> org.gradle.daemon=false
> org.gradle.jvmargs=-Xmx5192m -XX:+HeapDumpOnOutOfMemoryError
> -Dfile.encoding=UTF-8
>
> This is interesting because now, '*clean*' fails to find
> java.annotations.common, which it didn't before.  Also because Dagger is no
> longer in that stack trace.
>
> [0.174s][info][class,load] java.lang.module.ResolutionException source:
> jrt:/java.base
> Error occurred during initialization of VM
> java.lang.module.ResolutionException: Module java.annotation.common not
> found
>     at java.lang.module.Resolver.fail(java.base@9-ea/Resolver.java:785)
>     at java.lang.module.Resolver.resolveRequires(java.base@9-ea
> /Resolver.java:95)
>     at java.lang.module.Configuration.resolveRequiresAndUses(java.base@9-ea
> /Configuration.java:370)
>     at
> java.lang.module.ModuleDescriptor$1.resolveRequiresAndUses(java.base@9-ea
> /ModuleDescriptor.java:1979)
>     at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea
> /ModuleBootstrap.java:263)
>     at java.lang.System.initPhase2(java.base@9-ea/System.java:1928)
>
>
>
>
> Malachi de Ælfweald
> http://www.google.com/profiles/malachid
>
>
>
> On Tue, Jul 5, 2016 at 11:11 AM, Stephen Felts <stephen.fe...@oracle.com>
> wrote:
>
> You need to also pass the correct information to the daemon using
> something like the following (you can replace the argument files with the
> in-line information).
>
>
>
> GRADLE_OPTS=@/mydir/jdk9args -Xmx2048m
> -Dorg.gradle.jvmargs="@/mydir/jdk9args -Xmx2048m "
>
>
>
> *From:* Malachi de Ælfweald [mailto:malac...@gmail.com]
> *Sent:* Tuesday, July 05, 2016 1:52 PM
> *To:* Stephen Felts
> *Cc:* Remi Forax; jigsaw-dev@openjdk.java.net
> *Subject:* Re: JDK9 Modules
>
>
>
> 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
> >
> >
> >
>
>
>
>
>
>
>
>
>
>
>

Reply via email to