Guice 4.1.0 throws an exception from within the embedded cglib with
this release:

>java -version
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+135-jigsaw-nightly-h5500-20160914)
Java HotSpot(TM) 64-Bit Server VM (build
9-ea+135-jigsaw-nightly-h5500-20160914, mixed mode)

> [apptest]

   > Caused by: java.lang.NoClassDefFoundError: Could not initialize
   >    at$FastClass$Generator.getProtectionDomain(
   >    at$AbstractClassGenerator.create(
   >    at$FastClass$Generator.create(
   >    at
   >    at
   >    at
   >    at
   >    at
   >    at$000(
   >    at$1.create(
   >    at$1.create(
   >    at$1.load(
   >    at$LoadingValueReference.loadFuture(
   >    at$Segment.loadSync(
   >    at$Segment.lockedGetOrLoad(
   >    at$Segment.get(

We had it working just fine with:

Java(TM) SE Runtime Environment (build 9-ea+129-jigsaw-nightly-h5343-20160802)
Java HotSpot(TM) 64-Bit Server VM (build
9-ea+129-jigsaw-nightly-h5343-20160802, mixed mode)


On Thu, Sep 15, 2016 at 7:07 PM, Alan Bateman <> wrote:
> The EA download [1] has been refreshed with new builds that are mostly
> aligned with the current proposals for JPMS issues [2]. Not everything is
> there yet of course (and some areas need a few more iterations) but there is
> enough to test and try things out.
> For #ReflectiveAccessToNonExportedTypes and #AwkwardStrongEncapsulation then
> the initial support for `weak module` and `exports private` is in place.
> These are probably the highest priority changes to try out.
> The changes to setAccessible in #AwkwardStrongEncapsulation is going to be
> disruptive and will no doubt expose hacks in many areas. We've run into
> several of these already. The command line option to allow existing code to
> break into non-public types/members is --add-exports-private. The format of
> the value passed to this option is the same--add-exports. With
> #AddExportsInManifest then there are equivalents in the application JAR main
> manifest to try out too.
> As part of the #ClassLoaderNames then the format of the stack trace elements
> has changed.
> For #ServiceLoaderEnhancements then the implementation is mostly aligned,
> except for the static factory method which needs an update to javac and SL
> to align with the proposal (should be there soon, just not in this build).
> Several people have brought up #ResourceEncapsulation and
> #ClassFilesAsResources here so it would be good to try this out.
> As always, the most valuable feedback is from those trying out the builds so
> please let us know what you have tried and what works or doesn't work.
> -Alan
> [1]
> [2]

Reply via email to