Guice: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1

[gripedthumbtacks]

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

affecting oracle java9 with maven

[davido]

I'm seeing this too on Gerrit Code Review, and further warnings:

WARNING: Illegal reflective access by com.google.inject.assistedinject.FactoryProvider2$MethodHandleWrapper (file:/home/davido/.gerritcodereview/tmp/gerrit_13189476373589339762_app/guice-assistedinject-4.1.0.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)

[IliasKar]

Also shown when running hadoop 3.0.0 with JDK9
pplication application_1522866364341_0002 failed 2 times due to AM Container for appattempt_1522866364341_0002_000002 exited with exitCode: 1
Failing this attempt.Diagnostics: [2018-04-04 21:42:23.732]Exception from container-launch.
Container id: container_1522866364341_0002_02_000001
Exit code: 1
[2018-04-04 21:42:23.738]Container exited with a non-zero exit code 1. Error file: prelaunch.err.
Last 4096 bytes of prelaunch.err :
Last 4096 bytes of stderr :
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$2 (file:/home/karalis/hadoop/hadoop-3.0.0/share/hadoop/yarn/lib/guice-4.0.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[te21wals]

Has this been resolved?

[kibertoad]

Should this be fixed within Guice or within the cglib?

[Maia-Everett]

Still happening for me with 4.2.0, even though its release notes list it as Java 9 compatible.

[swankjesse]

Switching from cglib to ByteBuddy would be a nice fix.

[Hronom]

What progress with this? Got it on Spring Boot projects on Java 10. Is ByteBuddy will fix that?
I think this is actual nowadays since there comes Java 11 and Spring will start to support it oficially, It's big thing in Java world.

Also maven-compiler-plugin is somehow depends on this library
https://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html

So this affects all projects with maven.

[GedMarc]

Very easy to fix...
System.setProperty("com.google.inject.internal.cglib.$experimental_asm7", "true");

Then
--add-opens java.base/java.lang=com.google.guice,javassist

[ToxicMushroom]

this warning is really anoying pls fix

[mkurz]

Did you try latest release 4.2.2?

[GedMarc]

Without add-opens

Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: java.lang.reflect.InaccessibleObjectException-->Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to module com.google.guice
    at [email protected]/com.google.inject.internal.cglib.core.$ReflectUtils.defineClass(ReflectUtils.java:464)
    at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator.generate(AbstractClassGenerator.java:336)
    at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
    at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
    at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache$2.call(LoadingCache.java:54)
    at java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
    at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:61)
    at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.get(LoadingCache.java:34)
    at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
    at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:291)
    at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory$Generator.create(KeyFactory.java:221)
    at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:174)
    at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:153)
    at [email protected]/com.google.inject.internal.cglib.proxy.$Enhancer.<clinit>(Enhancer.java:73)
    ... 28 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to module com.google.guice
Caused by: java.lang.ExceptionInInitializerError
    at [email protected]/com.google.inject.internal.ProxyFactory.<init>(ProxyFactory.java:87)
    at [email protected]/com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:82)
    at [email protected]/com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29)
    at [email protected]/com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37)
    at [email protected]/com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33)
    at [email protected]/com.google.inject.internal.FailableCache$1.load(FailableCache.java:40)
    at [email protected]/com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3528)
    at [email protected]/com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2277)
    at [email protected]/com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154)
    at [email protected]/com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044)
    ... 18 more

[GedMarc]

Should I remove the system property?

[cplerch]

Sadly, the same issue here:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/C:/_/dev/repos/m2/com/google/inject/guice/4.2.2/guice-4.2.2.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

My setup:

• Windows 10
• Gradle 4.10
• OpenJDK 11+28
• Guice 4.2.2

Looks to me that no progress has been made on this issue by just updating guice to the newest cglib & asm versions.

[cplerch]

Some findings:

Adding VM option --add-opens java.base/java.lang=com.google.guice,javassist as suggested above gives another warning:

WARNING: Unknown module: com.google.guice specified to --add-opens
WARNING: Unknown module: javassist specified to --add-opens

However, after adding VM option --add-opens java.base/java.lang=ALL-UNNAMED all warnings disapear.

System.setProperty("com.google.inject.internal.cglib.$experimental_asm7", "true"); is obviously not needed anymore.

[GedMarc]

That looks like you aren't running in modular mode, plus opening all-unnamed you mine-as-well not use modules at all

Are you starting your app using the modular system?
java -m modulename/my.package.publicvoidmainclass

e.g. mine is

java.exe --add-opens java.base/java.lang=com.google.guice,javassist -Dfile.encoding=UTF-8 -m com.jwebmp.examples.demos.homepage/com.jwebmp.examples.demos.homepage.HomePageStartup

[Yanson]

Above fix does remove warnings.
For Gradle application plugin:

applicationDefaultJvmArgs = ['--add-opens', 'java.base/java.lang=ALL-UNNAMED']

[mcculls]

Note there are 2 different issues when using Java9+

• first was the introduction of new bytecode - this has been handled by upgrading ASM, and also CGLIB because it in turn needs to tell ASM to process the new bytecode level
• second the introduction of JPMS has brought in new access checks when running applications on the module path - this can lead to warnings for code that uses reflection, like Guice's use of AOP

The second issue will require more changes to CGLIB to use the new lookup API when running on JPMS, rather than reflection. (Either that or switch to use ByteBuddy)

Until then running applications using the classic classpath shouldn't trigger warnings, because the new module access checks don't kick in. Similarly using --add-opens java.base/java.lang=<module-name> to grant access to modules on the module path that use reflection should also remove the warnings.

If you don't need AOP then you could also consider using the no-AOP build which doesn't use ASM or CGLIB, and shouldn't trigger these warnings.

[GedMarc]

Also found when using Guice - it's better to have an open module for your running app rather than opens/exports package to com.google.guice (for AOP) - especially for larger projects, the module-info gets bloated and it becomes a little messy.

open module running.app{
        requires com.google.guice;
    requires javax.inject;
    requires aopalliance;
}

[ToxicMushroom]

Did you try latest release 4.2.2?

yes
edit: I'm just gonna ignore the warning by adding --add-opens java.base/java.lang=ALL-UNNAMED as jvm argument

[GedMarc]

In other news -
Byte buddy doesn't seem to gel with hibernate as yet, Guice is cruising..
java.lang.NoClassDefFoundError: net/bytebuddy/NamingStrategy$SuffixingRandom$BaseNameResolver

[marx-freedom]

Hello.
There is one non trivial thing...
--add-opens flag does not work for custom module layers.

My application creates a custom module layer (on top of the java boot layer) and loads guice module in that layer. --add-opens does not work because it applied only to the boot layer, and boot layer does not contain guice module at it's construction time so that flag is just ignored.

Error on Java 11:

Caused by: com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalStateException: Unable to load cache item
        at [email protected]/com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2050)
        at [email protected]/com.google.common.cache.LocalCache.get(LocalCache.java:3952)
        at [email protected]/com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3974)
        at [email protected]/com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4958)
        at [email protected]/com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4964)
        at [email protected]/com.google.inject.internal.FailableCache.get(FailableCache.java:51)
        at [email protected]/com.google.inject.internal.ConstructorInjectorStore.get(ConstructorInjectorStore.java:48)
        at [email protected]/com.google.inject.internal.ConstructorBindingImpl.initialize(ConstructorBindingImpl.java:155)
        at [email protected]/com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.java:595)
        at [email protected]/com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:932)
        at [email protected]/com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:852)
        at [email protected]/com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:291)
        at [email protected]/com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:222)
        at [email protected]/com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:938)
        at [email protected]/com.google.inject.internal.FactoryProxy.notify(FactoryProxy.java:48)
        at [email protected]/com.google.inject.internal.ProcessedBindingData.runCreationListeners(ProcessedBindingData.java:60)
        at [email protected]/com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:133)
        at [email protected]/com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:106)
        at [email protected]/com.google.inject.Guice.createInjector(Guice.java:87)
        at [email protected]/com.google.inject.Guice.createInjector(Guice.java:69)
        at [email protected]/com.google.inject.Guice.createInjector(Guice.java:59)
        at myapp.m1/myappclass(myapp.java:73)
        ... 7 more
Caused by: java.lang.IllegalStateException: Unable to load cache item
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:79)
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.get(LoadingCache.java:34)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:291)
        at [email protected]/com.google.inject.internal.cglib.reflect.$FastClass$Generator.create(FastClass.java:65)
        at [email protected]/com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:258)
        at [email protected]/com.google.inject.internal.BytecodeGen.newFastClassForMember(BytecodeGen.java:207)
        at [email protected]/com.google.inject.internal.DefaultConstructionProxyFactory.create(DefaultConstructionProxyFactory.java:49)
        at [email protected]/com.google.inject.internal.ProxyFactory.create(ProxyFactory.java:156)
        at [email protected]/com.google.inject.internal.ConstructorInjectorStore.createConstructor(ConstructorInjectorStore.java:92)
        at [email protected]/com.google.inject.internal.ConstructorInjectorStore.access$000(ConstructorInjectorStore.java:29)
        at [email protected]/com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:37)
        at [email protected]/com.google.inject.internal.ConstructorInjectorStore$1.create(ConstructorInjectorStore.java:33)
        at [email protected]/com.google.inject.internal.FailableCache$1.load(FailableCache.java:40)
        at [email protected]/com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3528)
        at [email protected]/com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2277)
        at [email protected]/com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154)
        at [email protected]/com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044)
        ... 29 more
Caused by: java.lang.ExceptionInInitializerError
        at [email protected]/com.google.inject.internal.cglib.core.$DuplicatesPredicate.evaluate(DuplicatesPredicate.java:104)
        at [email protected]/com.google.inject.internal.cglib.core.$CollectionUtils.filter(CollectionUtils.java:52)
        at [email protected]/com.google.inject.internal.cglib.reflect.$FastClassEmitter.<init>(FastClassEmitter.java:69)
        at [email protected]/com.google.inject.internal.cglib.reflect.$FastClass$Generator.generateClass(FastClass.java:77)
        at [email protected]/com.google.inject.internal.cglib.core.$DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator.generate(AbstractClassGenerator.java:329)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache$2.call(LoadingCache.java:54)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:61)
        ... 46 more
Caused by: com.google.inject.internal.cglib.core.$CodeGenerationException: java.lang.reflect.InaccessibleObjectException-->Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to module com.google.guice
        at [email protected]/com.google.inject.internal.cglib.core.$ReflectUtils.defineClass(ReflectUtils.java:464)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator.generate(AbstractClassGenerator.java:336)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:93)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:91)
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache$2.call(LoadingCache.java:54)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.createEntry(LoadingCache.java:61)
        at [email protected]/com.google.inject.internal.cglib.core.internal.$LoadingCache.get(LoadingCache.java:34)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:116)
        at [email protected]/com.google.inject.internal.cglib.core.$AbstractClassGenerator.create(AbstractClassGenerator.java:291)
        at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory$Generator.create(KeyFactory.java:221)
        at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:174)
        at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:157)
        at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:149)
        at [email protected]/com.google.inject.internal.cglib.core.$KeyFactory.create(KeyFactory.java:145)
        at [email protected]/com.google.inject.internal.cglib.core.$MethodWrapper.<clinit>(MethodWrapper.java:23)
        ... 57 more
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to module com.google.guice
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
        at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
        at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
        at [email protected]/com.google.inject.internal.cglib.core.$ReflectUtils$1.run(ReflectUtils.java:61)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at [email protected]/com.google.inject.internal.cglib.core.$ReflectUtils.<clinit>(ReflectUtils.java:52)
        at [email protected]/com.google.inject.internal.cglib.reflect.$FastClassEmitter.<init>(FastClassEmitter.java:67)
        ... 54 more

[GedMarc]

So I have no idea why, which one, or how it works... (probably cglib?) but......
4.2.2
Adding in the following to my maven pom allows me to remove all command line options

      <dependency>
                <groupId>cglib</groupId>
                <artifactId>cglib</artifactId>
                <version>3.2.9</version>
                <scope>provided</scope>
                <optional>true</optional>
            </dependency>

<dependency>
                <groupId>org.javassist</groupId>
                <artifactId>javassist</artifactId>
                <version>3.23.1-GA</version>
                <type>jar</type>
                <exclusions>
                    <exclusion>
                        <artifactId>xml-apis</artifactId>
                        <groupId>xml-apis</groupId>
                    </exclusion>
                </exclusions>
            </dependency>

<plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-compiler-plugin</artifactId>
                        <version>3.8</version>
                        <dependencies>
                            <dependency>
                                <groupId>org.ow2.asm</groupId>
                                <artifactId>asm</artifactId>
                                <version>7.0</version>
                            </dependency>
                        </dependencies>
                        <configuration>
                            <release>11</release>
                        </configuration>
                    </plugin>

[luigi-riefolo]

any update?

[innovationhub-asia]

+1

[GedMarc]

It is fixed and correct, there is nothing more needing to be done

• The library is correctly blocked from reflecting on java.lang, the opens clause correctly fixes this
• JPMS is strict encapsulation, so your packages have to be "open" to private/protected field inject, (which is now a bug, so dont ever field reflect again)
• Entertaining strict encapsulation correctly fixes any opens clauses
• Opening the base module, opens all the jdk modules (except for jdk.unsupported), this is why an open module works
• Opening your module does not break strict encapsulation beyond your module, every requires is still in its chains and constraints, minimal performance impact is felt by opening your module.
• While a bit lazy, specifying the running base module as open also removes any --add-opens clause you need making it feel exactly like previous JRE's.

I strongly feel this issue can be closed as fixed, as it is correct, and it is adhering to JPMS standards.

[mkeller-ergon]

You mean the fix ist, that everyone needs to add an --add-opens to java.lang for guice??

[GedMarc]

Yes, That's called Strict Encapsulation. That's called, perfection.
You can be lazy as well however.

Option 1 for strict encapsulation and pure JPMS, and yes it is correct, and amazing, and unbelievably blazing fast.
Option 2 is opening your base module so that the java.base/java.lang automatically assumes opened. The module hierarchy is still maintained, and all your classes still execute in the modular engine,

open module my.module {
}

Welcome to the future! It's scary, but it is honestly amazing, if you are willing to put the old tools down, and pick the new tools up.

[GedMarc]

An example of each method :

1) Strictly Defined Enterprise Web App Example - https://github.com/GedMarc/JWebMPHomePage/blob/master/src/jre11/java/module-info.java
2) Loosly Defined Enterprise Web App Example - https://github.com/GedMarc/JWebMPHomePage/blob/master/src/jre11/java/module-info_openmodule.txt

This is running hibernate 3.5.7 persistence with hazelcast 3.10.4 100% modular with (btm-jpms), (uadetector-core-jpms), (guiced-injection), etc etc. There is also Rabbit MQ managing JMQ

I chose the ugly way in fact, i prefer the modular hierarchy strict and don't mind using --add-opens, plus there's is a 260ms drop in boot time
JRE 8 to pure JPMS is a 8 second drop in boot time from 11 seconds to 3, which is always nice.

I'm a fan of it now (if you haven't noticed), but truly hated it, as I guess we do with everything new.

[ipkpjersi]

I am using Guice 4.2.2. Is this something that Google can and will fix in the future? Does this mean my application that uses Guice with an injector will stop working in newer versions of Guice (or newer versions of Java)? The part of this message that concerns me is this as I am not sure what it means:

WARNING: All illegal access operations will be denied in a future release

I just spent two days re-writing my application so it no longer uses Java's Nashorn, I'd hate to have to re-write it again so it no longer uses Guice...

[GedMarc]

Why don't you write your application to adhere to JPMS?

All private and protected field reflection, and all proxying and interception, no matter the library will have this, and again, it is correct. Don't remove your libraries, define your application correctly?
It is only supported now to help you move across, but make no mistake if you want open classpaths and illegal access, you will be stuck no matter what you do, on JRE 8, through no fault of any library.

The problem here is the inability to mold to the new and much better structure, not the libraries.

Regarding nashorn : https://github.com/junit-team/junit5/issues/1481

[ipkpjersi]

I'm not sure I understand how libraries throwing an error means I'm writing my application incorrectly when the error explicitly says: WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1

What does that have to do with my code and my application? What do you mean define my application correctly?

I literally just upgraded from Java 8 to Java 11 all in one go so all of these errors and warnings I received are confusing. Java is starting to feel more like a community project rather than a robust, enterprise company-backed language.

How is libraries throwing a warning (and it sounds like eventually an error) my fault in any way when the warning tells me to report it to the maintainers of the library?

How come Google is not commenting on this issue when it sounds to be an issue with changes that will need to be made in their library for future versions of Java?

Does this mean guice will no longer work at all and entirely break my application, or does it mean this one part of guice will stop working but the rest will be fine? None of this is very clearly defined.

[FeanorsCurse]

I feel exactly the same way. And if using a library in its default configurations means getting errors then something is definitely amiss - or not at all properly explained or set up.

[GedMarc]

I don't think you understand JPMS,

You can't just "Move from JRE8 to JRE11", not possible.
You can't enable AOP without opening the package to google guice,
You can't inject private and protected without opening the package to google guice.
You simply just can't do it.

You're asking to rollback JPMS so your application that ran in JRE 8 will run in JRE 11, if that's what you want, then run in classpath mode which will be completely dropped in JRE12 and no illegal access at all will be used, and that will be the limit of JRE updates you will ever do.

If you don't jump on the boat for JPMS, don't complain about your ClassPath app not working in a modular system.

They are not commenting on the issue, because there is no issue other than a lack of fundamental understanding on your part.

[GedMarc]

Guice works just fine in JPMS, so much so that I have JTA, JPA, MQ, Proxying, and everything else running under it. Problem here is not Guice.

[ebourg]

then run in classpath mode which will be completely dropped in JRE12

AFAIK there is no plan to remove the classpath in Java 12. The modulepath and the classpath are going to coexist for a long time.

[GedMarc]

as far as I'm aware, JDK 12 Is the last JRE with relaxed illegal access (JEPS261), JRE 13 will be purely strict only.

If you are still confused about your very standard jdk error - https://blog.codefx.org/java/java-11-migration-guide/#Illegal-Access-To-Internal-APIs

Here's what you need to do, create an open module, or open java.base so that you tell java to enable proxy classes.
Whether you use byte buddy, cglib, javaassist or even just custom proxying, you will have to perform these steps.
If you don't want to do that and stick with classpathing, you need to understand that your development path has an end date, but you can always just --illegal-access=allow which is definitely not recommended but will do what you want it to.

Your message is saying cglib is trying to proxy, but you haven't allowed cglib to proxy anything.

[ipkpjersi]

This is very confusing to me. So I fixed illegal access to internal APIs - that's easy, I just removed all sun.* and com.sun.* imports and replaced it with either identical java.* imports or simply re-wrote sections of code. That's fine.

I have no idea what JPMS is or what these classpath vs modulepath changes are all about. I load in dependencies (libraries) for one of my applications with gradle and another application just through my IDE. Does this mean that the way all dependencies are loaded will have to change - both for gradle and otherwise, from "classpath" to "modulepath"? I don't even know what classpathing is, nor what illegal reflective access is or modulepathing or even what proxying is. I don't understand why some libraries throw this warning while others do not. I have asked literally 5 of my most expert Java friends and they don't even know what JPMS is let alone the steps required here to fix this issue. I am at a loss here.

[GedMarc]

Um, shew, that's a topic for a different thread. But I guess it may help a bit?

This is my experience, if I am incorrect in any way please correct me, I am learning just as much as everyone else!

So it's very easy actually, there's a curse with backwards compatibility, anything "new" has to be done differently, you can't change existing things, just "update" them (like FileOutputStream to FileChannel had to be new, where-as a simple update to the math class would suffice with floating methods. Some classes like util.properties have been incorrect with types and a random serial version id since 1.0
It only changed to a class version in 1.03, it should have just been 1L, and in JDK 1.4 the structure should have removed hashtable, but the JDK has been getting dirtier and dirtier and slower and slower just to support this backwards compatibility, and we've been getting too used and too comfortable with it.

So yes, the JVM has changed enormously, but still backwards compatible, you have to add stuff to command line sometimes to enable things that should have not been possible without any a strict specification ;)

JPMS is a change in how classes are loaded and accessed, it fixes it, and adheres to all encapsulation defined by OO and adds a new layer of encapsulation on the package horizontal layer

It's a method of class containing and loading (without container loaders ejb/war/etc) that strictly enforces access to certain packages correctly, and too associated libraries. Instead of a bundle of mud, a proper domain driven platform that is clean, contained, and internal public classes in external libraries are no accessible (oh thank gawd)

It is a full replacement for

• Class Containments (The purpose for EE to exist)
• OSGi (It is naturally built in)
• Object Pooling (Class Data Sharing)
• Downwards Injection (Using that fastest way imaginable to load classes - SPI JDK1.6 rewritten for JDK1.9)
  It is not a replacement for
• Distributed Computing (It is domain driven so Centralized Computing is the way to go, rest services, micro modules etc)

JPMS is enabled by added a module-info.java file to the root of your sources and has a completely new structure which you can read about everywhere with a google.

After struggling and 140 projects using this darn thing, It is fast, it is clean, the code is fantastic. The module-info in enterprise application could get disgusting as the examples up top show, but the performance impact is minimal currently with regards to just opening the base module

https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction

Sorry for destroying the thread.

[ipkpjersi]

So in Java 12/13, in order to solve this warning from turning into an error I need to create a module-info.java and essentially somehow reference that I would like to use guice for my application, and then the rest of my application should continue working and this warning/error should be gone? Is that correct?

I don't think we're destroying this thread, I think we're improving it by trying to find a resolution to this issue that people are coming across - and likely many more people will come across in the future and may end up being even more confused than I am.

[GedMarc]

Here is a full RAW JPMS Guice Implementation, I do not know Gradle, but everything can open pom's :

guiced-jpms.zip

Output

[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ helloworld-jpms ---
Configure Imported Module Called. This will make the warning
Configure Exported Module Called. This will not make the warning
Calling method : interceptMe
Was annotated with : This Was Intercepted
Intercepted
Successful
This wont intercept because it is not created by guice
Downward Injection Do Something
This will intercept because it is constructed through guice
Downward Injection Do Something
Done

[ipkpjersi]

So I'm still confused, but I think some of the confusion is starting to clear up - hopefully other people reading all of this can benefit from this because this is a whole lot to take in from just a 5 line warning that the original post had.

I have an application (technically two, one with gradle one without gradle) that uses guice-4.2.2.jar as a dependency. My application creates an injector using guice, and does a bunch of other stuff with other dependencies as well. I want to make it so that my application no longer throws this issue which will eventually be an error. How do I go about doing that?

Do I simply do what you did with the module-info.java and module-info.txt? Do I only need to do this only for guice, or do I need to do this for all dependencies (libraries) I load (either via gradle or otherwise) after Java 12/13 even if the other dependencies are not throwing any issues/errors?

[GedMarc]

Oh, No, Only for injection libraries, like guice, weld, spring, etc etc

So far my list is
opens xxx to com.fasterxml.jackson.databind, com.google.guice, javax.xml.bind

This is @Annotated fields to be read and deseriealized into JSON, XML and gets injected by Guice
Any library that reads private and protected fields is affected and will need an opens clause.

And when there is hibernate i need to open my entities for the byte buddy proxies, I'm a using an object query engine called entity assist that also reads @Column data.

opens xxx to org.hibernate.orm.core, com.fasterxml.jackson.databind, com.google.guice;

When you run the app on startup it will actually tell you "this package doesnt open to com.google.guice"

[ipkpjersi]

Here is the simple answer of fixing this issue after my experimenting most of today.

Assuming your code is in a folder called: org.package

module org.package {
    requires com.google.guice;
}

and we may need to require other dependencies, for example if we are using swing the compiler may throw this error:
Error:(15, 13) java: package javax.swing is not visible(package javax.swing is declared in module java.desktop, but module src does not read it)

then we would need to also add requires java.desktop;
then we should be able to compile our program, and the warning/error about illegal reflective access should be gone. However, I have not been able to test this as my program requires other dependencies to be declared as modules and unfortunately for example lombok does not have full module support yet.

Here is a great article for reading more about Java 9 modules: https://gorillalogic.com/blog/understanding-java-9-modules/(edited)

[GedMarc]

Lombok works fine with JPMS, the problem is elsewhere

A library does not need to be a module in order to work with JPMS, it will assume automatic naming mechanism,
Lombok is not a library nor a dependency but an annotation processor. It should never be packaged with your app AT ALL in any circumstance, or declared a dependency for any application

for maven

 <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.0</version>
                <configuration>
                    <source>${project.java.version}</source>
                    <target>${project.java.version}</target>
                    <encoding>${project.build.sourceEncoding}</encoding>
                    <!--<compilerArgument>-proc:none</compilerArgument>-->
                    <annotationProcessors>
                        <annotationProcessor>lombok.launch.AnnotationProcessorHider$AnnotationProcessor</annotationProcessor>
                    </annotationProcessors>
                <annotationProcessorPaths>
                    <annotationProcessorPath>
                        <groupId>lombok</groupId>
                        <artifactId>bla bla bla</artifactId>
                        <version>latest version</version>
                    </annotationProcessorPath>
                </annotationProcessorPaths>
            </configuration>
                </configuration>
            </plugin>
</plugins>

[ipkpjersi]

I'm not the only one with issues with Lombok not working under Java 11: https://github.com/rzwitserloot/lombok/issues/1723

I don't use Maven, I use Gradle. How would I use Lombok with that? I have seen lots of applications packaged with Lombok as a dependency.

[GedMarc]

urgh, enough.

[ipkpjersi]

Upon doing more research and testing, I think this may be something that the guice package maintainers can fix. For example, I was using netty-all version 4.1.13 in one of my projects and I noticed that they had fixed illegal reflective access: https://github.com/netty/netty/issues/8318 in version 4.1.30, so I upgraded to netty-all 4.1.30 and I noticed that the warning had gone away. Also, pgjdbc has fixed illegal reflective access here: https://github.com/bolcom/pgjdbc/commit/586525744aa4c7973375f862a54043ea383d230d

So, I think there is a reason why it says "please consider reporting this to the maintainers" - this is something that they should in theory be able to fix.

edit: instead of voting my comment down without explanation, why not simply explain why you believe that the maintainers of guice will not be able to or should not change guice so that it does not use illegal reflective access despite how netty-all's maintainers had updated netty-all to not use illegal reflective access? Shouldn't open-source development encourage open and friendly discussion?

[ipkpjersi]

Tagging @sameb

Is this anything you might be able to fix (removing the reflective access, like how netty-all removed reflective access in their library by not relying on a sun.* class)? I really would like to see this get fixed so I don't have to use JPMS to avoid this warning (and eventually error, plus JPMS causes other issues for me currently) and so I can just continue using guice in Java 12 and onward. Of course this isn't particularly high priority but is this something that could possibly be done down the road?

edit: I see you have commented on this in #1205 but this issue is still present for me in guice 4.2.2

[nextdtinc]

Can this please be fixed? It's 2019, I'm using all the latest libraries, and Guice is polluting my output with this irrelevant error message.

[Hronom]

@nextdtinc hope in 2020 it will be fixed

[GedMarc]

is it not fixed? are you not extending the java.base/java.lang module definitions to allow guice to override/extend the classes?

[BjoernPetersen]

I wouldn't consider it fixed as long as Guice (via cglib) uses the ClassLoader.defineClass(...) method. If the issue was "fixed", people would not be required to open java.base/java.lang. Apparently the cglib-people are not going to change that though, because cglib is no longer actively developed.

Interesting blog post about that: https://mydailyjava.blogspot.com/2018/04/jdk-11-and-proxies-in-world-past.html

I'm not sure how feasible it is, but have you looked into switching to Byte Buddy or Javassist?

[mcculls]

I'm experimenting with moving Guice to Byte Buddy - early days, but no blockers yet

[sameb]

very neat stuart, let me know how it goes or if you'd like any help along the way.

[ipkpjersi]

Hey @mcculls how goes moving Guice to ByteBuddy? Is there a branch of a repository or possibly a separate issue where we can follow the progress of this or if you run into any blockers?

I see someone had mentioned that gclib is no longer maintained, but I saw an update to it 8 days ago. Is it possible that gclib will fix this illegal reflective access so that it may not be necessary to switch to Byte Buddy unless Byte Buddy provides additional benefits over gclib?

I'd love to see this illegal reflective access issue go away before it starts getting denied by default and outright no longer working at all in future Java versions.

[doctorpangloss]

might as well not use modules at all

🔔 🔔 🔔

Also it would appear that plugin-style injection doesn't work in my Travis environment due to this issue? I also use PowerMockito, so there's something very funky about how the two interact (https://github.com/ESAPI/esapi-java-legacy/issues/496)

Edit: I can confirm there is no weird interaction between PowerMockito, Travis and Guice on Gradle 5.5 & OpenJDK 11.

[bbottema]

What's the current status? I'm having this with Java 12 and Guice 4.2.2.

[Funnear]

[email protected]:/# mvn archetype:generate                      \
>    "-DarchetypeGroupId=io.cucumber"           \
>    "-DarchetypeArtifactId=cucumber-archetype" \
>    "-DarchetypeVersion=4.2.6.1"               \
>    "-DgroupId=my-stuff"                  \
>    "-DartifactId=my-stuff"               \
>    "-Dpackage=my-stuff"                  \
>    "-Dversion=1.0.0-SNAPSHOT"                 \
>    "-DinteractiveMode=false"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[mcculls]

Sorry for the lack of updates: I've decoupled all uses of CGLIB in an experimental branch and introduced a set of interfaces that cover what Guice needs. I'm currently implementing those with generators that work with recent versions of the JVM. Will post a bit more detail later this week.

[mkurz]

@mcculls Can you give more details and maybe an ETA? Thanks!

[avoloshko]

How is the progress?

[paplorinc]

Hey @mcculls, thanks for tackling this.
This prohibits us at Gradle Enterprise to upgrade to JDK 11, could you please give us an update on the ByteBuddy migration progress?
Thanks! :)

[paplorinc]

Any update?

[kaungmyatpaing21]

Is this problem corrected?
If so, can u give me detail instructions on how to fix?

[sclassen]

I found the following branch with no commits since April 6
https://github.com/mcculls/guice/tree/experiments

[mcculls]

Yes I'm still working on this (balancing it with my day job and family commitments, which is why unfortunately it is taking longer as expected as the last few months have been very busy on both fronts)

I did find a good chunk of time last weekend which helped move things along, and hope to do the same this weekend.

[cyrilfr]

I experience the same warnings with a Play Framework 2.6 app running in an adoptopenjdk/openjdk11:alpine Docker container.

[GedMarc]

Here's a neat trick -

set a new environment variable like so -
JDK_JAVA_OPTIONS=--add-opens java.base/java.lang=com.google.guice
(https://www.oracle.com/technetwork/java/javase/9-new-features-3745613.html)

Run your program. This will also have no effect on any other program running it simply says a warning "unknown module".
Another tip, for hibernate, you can set it like so
JDK_JAVA_OPTIONS=--add-opens java.base/java.lang=com.google.guice,javassist

I don't know how many people still use Guice, or want to take the apps into the modular world,
but https://www.guicedee.com is really really close to the 1.0.0.Final release, the guice libraries are all strictly typed and named for JLink, JMod and JPackage applications. Quite a good bunch of addons I think as well?

100% compliant.
All the links on the site for the modules are working, the page links i'm hoping to have finished by the week.

Asking for some testing help making sure it all works as intended :)

https://www.guicedee.com

[mkurz]

Any updates? @mcculls Are you still working on a fix?

[mcculls]

Yes I'm still working on this, just sorting out the last piece of glue for enhanced classes.

[Grinderwolf]

@mcculls When do you think the fix could be finished?

[domisum]

@mcculls What's the current state of things?

[mcculls]

@domisum still working on it in my spare time - but family and work have kept me very busy in the new year. Hopefully will get some time soon to wrap up the last bits of generated code.

[mkurz]

@mcculls Thanks a lot for you efforts!

[faystmax]

@mcculls +1

[shtomik]

@mcculls +1

[hanibhat]

Some findings:

Adding VM option --add-opens java.base/java.lang=com.google.guice,javassist as suggested above gives another warning:

WARNING: Unknown module: com.google.guice specified to --add-opens
WARNING: Unknown module: javassist specified to --add-opens

However, after adding VM option --add-opens java.base/java.lang=ALL-UNNAMED all warnings disapear.

System.setProperty("com.google.inject.internal.cglib.$experimental_asm7", "true"); is obviously not needed anymore.

Where to add --add-opens java.base/java.lang=ALL-UNNAMED?

[GedMarc]

As an environment variable in your O.S.

JDK_JAVA_OPTIONS=--add-opens java.base/java.lang=com.google.guice,javassist

The change does generate the given warning as a system wide operation, and is catered for as the standard ref (http://bugs.java.com/view_bug.do?bug_id=JDK-8170832), introduced in JDK 9 as a safe usage for having both JDK 8 and JPMS on a single system.

https://www.oracle.com/technetwork/java/javase/9-new-features-3745613.html

https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-3B1CE181-CD30-4178-9602-230B800D4FAE

It is not a good idea to "ALL-UNNAMED" anything, although yes you can do it and it will definitely work. Your application will not be JImage compatible, a.k.a won't be able to build JMod, JLink and JPackage for distribution.

[Mishamba]

i think, that no one, can solve this problem))

[GedMarc]

It's not a problem, it's by design.
People are looking for a way to go back to open classpath's without warnings that they aren't moving forward.
The forward movement of Java is modularization, so it's competing designs and lots of people aren't comfortable with change.
That's all that's happening here

[cyrilfr]

I don't think there is unsolvable software problem. If the solution isn't possible that way, there is one another way.

[mcculls]

Latest status: got a sizeable application with method interception working using my locally patched version of Guice and no illegal reflective access warnings using recent JDKs :)

Just a couple of failing unit tests to fix which should be sorted tomorrow. I'll put together some instructions at the same time along with an overview of all the changes/improvements in a PR. Should have it ready for people to try out and give feedback later this week.

[mkondratek]

I experience the issue too with:
Gradle 6.2
JDK11
Guice 4.2.2

[gosp]

About the warning. Someone said it is "unsolvable software problem".
I am curious why Spring is OK but Guice isn't OK. Both of them are DI frameworks.

[Cliabhach]

@mcculls Is there anything we can do to help out?

[GedMarc]

spring is not ok at all, it cannot run anything as modular (-m package/module)

[wolf99]

Seeing this error when running Maven quick start on Ubutnu 18.04:

$ mvn archetype:generate -DgroupId=com.example -DartifactId=generic-class
es-and-interfaces -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
[...]

[mcculls]

@wolf99 I assume that's using Ubuntu's own custom distribution of Maven? The official Maven distribution uses the "no-AOP" build of Guice which doesn't contain any CGLIB code. If you download an official distribution from https://maven.apache.org/ then you shouldn't see the warning.

[wolf99]

Reporting back for others that may have stumbled across the same issue as I, namely Maven installed from the 18.04 Ubuntu PPA (probably using apt install maven).

I uninstalled the Maven from the PPA (apt remove maven) and installed the package from the Maven website (recorded instructions that worked for me here: https://github.com/wolf99/dotfiles/blob/master/how-to-update-maven.md).

This resolved the warning. Now you just need to remember that Maven needs to be updated manually.

[mcculls]

I've temporarily deployed a unofficial beta of Guice with the new AOP code to a Maven repository under https://github.com/mcculls/guice-betas/tree/gh-pages so adventurous users can try it out and report back while other testing and reviews continue.

There's also a source archive if people want to build or look over the code locally.

This an unofficial beta for community testing purposes and shouldn't be used in production

[petergeneric]

Passes unit our internal project unit tests without issue on JDK11 and JDK13, I also deployed a test build of an internal application relying heavily on AOP with this new code on JDK11 and had no issues, looking very promising!

[GedMarc]

I've been running this in prod on JDK 14 with no issues - even without the latest 2 commits...

[mkurz]

@mcculls Your beta runs smoothly when applied within Play Framework: https://github.com/playframework/playframework/pull/10202
Play uses Guice as default runtime DI framework, there a lot of tests, running both on JDK8 and JDK11, also cross build against Scala 2.12 and Scala 2.13:
https://travis-ci.com/github/playframework/playframework/builds/161231905
The beta looks very promising!

[colm-quinn]

@mcculls +1

[vincenzopalazzo]

+1

[emilm]

So when is this out on maven? :)

[wuliangx]

I am waiting for this to be out too.

[pickledbrill]

Have the same warning when using JDK 11 and plain maven project. The version of Guice is 4.1.

[peeeto]

+1

[colm-quinn]

I've temporarily deployed a unofficial beta of Guice with the new AOP code to a Maven repository under https://github.com/mcculls/guice-betas/tree/gh-pages so adventurous users can try it out and report back while other testing and reviews continue.

There's also a source archive if people want to build or look over the code locally.

This an unofficial beta for community testing purposes and shouldn't be used in production

Nice work with the unofficial beta!

Are there plans to roll this into an official Guice release? If so, is there any timeline that could be shared on when it would be available? This looks to be a small enough change that would have a large impact.

[mikail-khan]

@mcculls Your beta runs smoothly when applied within Play Framework: playframework/playframework#10202
Play uses Guice as default runtime DI framework, there a lot of tests, running both on JDK8 and JDK11, also cross build against Scala 2.12 and Scala 2.13:
https://travis-ci.com/github/playframework/playframework/builds/161231905
The beta looks very promising!

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/home/mikail/.cache/coursier/v1/https/repo1.maven.org/maven2/com/google/inject/guice/4.2.3/guice-4.2.3.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Getting this with Play 2.8.2. Not sure if I have followed the above thread correctly but will the Playframework be issuing a new release with the fix.

[sameb]

@mikail-khan it's unlikely that any official play release has incorporated the guice change yet, since we haven't released any official guice releases with it.

we're working on incorporating it (running it against _all_ of Google's tests and doing some code reviews).

@mcculls -- I'll be adding some comments to the PR early next week (been a busy month for me, and my daughter's bday is tomorrow, so i've been a bit backed up). mostly just questions, no big issues.. everything looks great.

[apflieger]

Just tested 4.2.4-20200419-NEWAOP-BETA on my project. It works fine 👍

[mkurz]

For the record: The pull request to fix this issue is #1298

[sameb]

fixed in https://github.com/google/guice/commit/85e30beafe55551a649025d3c12e831214057412.

[wuliangx]

Wow I've been waiting for this for very long, thanks! When will the official version containing this fix be released?

[2DSharp]

I have been eyeing this for quite some time. Took almost 3 years but I guess the wait is finally over.

[jianglai]

Can you cut a release so that we can actually use the fix? Thank you.

[rlogwood]

The issue repeats in #1216

[masuch]

Warnings still appearing:
java:
openjdk 14.0.1 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7-Ubuntu-1ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0.1+7-Ubuntu-1ubuntu1, mixed mode, sharing)
os:
Description: Ubuntu 20.04.1 LTS

./fix_engine.sh
Installing our local jbullet.jar and stack-alloc.jar into the maven local repository
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[ogregoire]

@masuch Have you tested against a custom build of Guice? Because I see that you use /usr/share/maven/lib/guice.jar which I heavily guess seems to be a proper release, not a custom build. The fix has not been released in a proper release yet, so if you would expect the warnings to disappear, you would have to have your own custom build of Guice at the moment.

[luneo7]

fixed in https://github.com/google/guice/commit/85e30beafe55551a649025d3c12e831214057412.

@sameb can you do a release with the fix?

[soc]

If you don't use Guice for AOP (e. g. only use it for injection), then replacing

<dependency>
  <groupId>com.google.inject</groupId>
  <artifactId>guice</artifactId>
  <version>4.2.3</version>
</dependency>

with

<dependency>
  <groupId>com.google.inject</groupId>
  <artifactId>guice</artifactId>
  <version>4.2.3</version>
  <classifier>no_aop</classifier>
</dependency>

might work around this issue.

(I'll skip the almost obligatory comment on how Google's handling of the open-source project under its control reflects on it. My personal lesson is that I'm slowly phasing out the existing use of open-source libraries owned by Google and banning the adoption of new ones, because if this is how things work, then depending on some random single-developer hobby project feels like a more reliable choice.)

[natros]

(I'll skip the almost obligatory comment on how Google's handling of the open-source project under its control reflects on it. My personal lesson is that I'm slowly phasing out the existing use of open-source libraries owned by Google and banning the adoption of new ones, because if this is how things work, then depending on some random single-developer hobby project feels like a more reliable choice.)

I completely agree with you.

[apflieger]

That's not how we should celebrate the 3rd anniversary of this issue folks.
In addition, there's no other DI library out there apparently.

(I still like you, Guice)

[Jazarro]

In addition, there's no other DI library out there apparently.

There is Dagger.

[natros]

In addition, there's no other DI library out there apparently.

I recently discovered that I could use the micronaut-inject without having to use the micronaut. I think I'm going to start replacing guice with the micronaut-inject, which has few dependencies.

+--- io.micronaut:micronaut-inject -> 2.1.0
|    +--- org.slf4j:slf4j-api:1.7.26
|    +--- javax.annotation:javax.annotation-api:1.3.2
|    +--- javax.inject:javax.inject:1
|    +--- io.micronaut:micronaut-core:2.1.0
|    |    +--- org.slf4j:slf4j-api:1.7.26
|    |    +--- org.reactivestreams:reactive-streams:1.0.3
|    |    \--- com.github.spotbugs:spotbugs-annotations:4.0.3
|    |         \--- com.google.code.findbugs:jsr305:3.0.2
|    \--- org.yaml:snakeyaml:1.26

docs: https://docs.micronaut.io/latest/guide/index.html#ioc

[apflieger]

Oh, I just discovered that Dagger is now forked by google. The original has no commit since 3 years.

[apflieger]

There's a beta release, peeps! 5.0.0-BETA-1
Let's try it out!

[mkurz]

Just upgraded to 5.0.0-BETA-1 in Play Framework, looks good:
https://github.com/playframework/playframework/pull/10506
https://travis-ci.com/github/playframework/playframework/builds/194217954

[apflieger]

I'm using it in production since 9 days now. Works fine

[soc]

Sadly, the no_aop artifact disappeared. Was this intentional?

[sameb]

@soc Yes, see the release notes @ https://github.com/google/guice/wiki/Guice500#guice-core

[froque]

I have tested 5.0.0-BETA-1 and detected no problems

[luneo7]

Is there a a rough roadmap or release date for the final version?

[luneo7]

Is there a a rough roadmap or release date for the final version?

@sameb @markmarch ?