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
>
>
>
