I got a total crackup almost instantly (jena-parent): https://gist.github.com/ajs6f/a1ff77fc683cba319257e7b80ba6e8b0
Looks like a problem with the Javadoc plugin, so upstream of us. I might try it out with some other projects to see what I get. [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.791 s [INFO] Finished at: 2016-12-09T09:51:29-05:00 [INFO] Final Memory: 26M/87M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar (attach-javadocs) on project jena-parent: Execution attach-javadocs of goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:jar: java.lang.ExceptionInInitializerError: null --- A. Soroka The University of Virginia Library > On Dec 9, 2016, at 8:41 AM, Andy Seaborne <[email protected]> wrote: > > If anyone is interested in trying to build Jena with java9 ... > > Oracle are running a major effort around JDK9 and looking for any and all > feedback from open source projects. > > Andy > > -------- Forwarded Message -------- > Subject: JDK 9 b148 including a refresh of the module system is available on > java.net > Date: Fri, 9 Dec 2016 10:05:52 +0000 > From: Rory O'Donnell <[email protected]> > Reply-To: [email protected] > > > JDK 9 build b148 <https://jdk9.java.net/download/> includes an important > Refresh of the module system [1] , summary of changes are listed here > <http://download.java.net/java/jdk9/changes/jdk-9+148.html>. > > *This refresh includes a disruptive change that is important to understand. > > *For those that have been trying out modules with regular JDK 9 builds then > be aware that `requires public` changes to `requires transitive`. In > addition, the binary representation of the module declaration > (module-info.class) has changed so that you need to recompile any modules > that were compiled with previous JDK 9 builds. > > As things stand today in JDK 9 then you use setAccessible to break into > non-public elements of any type in exported packages. However, it cannot be > used to break into any type in non-exported package. The current specified > behavior was a compromise for the initial integration of the module system. > It is of course not very satisfactory, hence the #AwkwardStrongEncapsulation > issue [2] on the JSR 376 issues list. With the updated proposal in the JSR, > this refresh changes setAccessible further so that it cannot be used to break > into non-public types, or non-public elements of public types, in exported > packages. Code that uses setAccessible to hack into the private constructor > of java.lang.invoke.MethodHandles.Lookup will be disappointed for example. > > This change will expose hacks in many existing libraries and tools. As a > workaround then a new command line option `--add-opens` can be used to open > specific packages for "deep reflection". For example, a really popular build > tool fails with this refresh because it uses setAccessible + core reflection > to hack into a private field of an unmodifiable collection so that it can > mutate it, facepalm! This code will continue to work as before when run with > `--add-opens java.base/java.util=ALL-UNNAMED` to open the package java.util > in module java.base to "all unnamed modules" (think class path). > > *Any help reporting issues to popular tools and libraries would be > appreciated. * > > A debugging aid that is useful to identify issues is to run with > -Dsun.reflect.debugModuleAccessChecks=true to get a stack trace when > setAccessible fails, this is particularly useful when code swallows > exceptions without any logging. > > > Rgds,Rory > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-November/005276.html > <http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html> > [2] > http://openjdk.java.net/projects/jigsaw/spec/issues/#AwkwardStrongEncapsulation > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > >
