Guice 6.0.0 version Uses internal APIs: sun.misc.Unsafe and not compatible with Java 17/21

[ilapavuluri]

Hi Team,

I am planning to run my application Java 21, when I run "jdeps --multi-release 21 -jdkinternals" scan I am getting below report for Guice 6.0.0 version

"Uses internal APIs: sun.misc.Unsafe "

Which version of Guice onwards it is compatible with Java 21?

Thanks
Ashok.

[GedMarc]

Guice 7 is compatible to JDK 23

[slawekjaranowski]

Maven is also affected:
https://issues.apache.org/jira/browse/MNG-8760

apache/maven#10312

[ilapavuluri]

@slawekjaranowski thank you for the update.

[slawekjaranowski]

@ilapavuluri for me issue still exist, so should not be closed as complete.

To be clear, should be commented, that is not planned and so on ... and close as not planned or not close when should be fixed.

[garretwilson]

Maven is also affected:
https://issues.apache.org/jira/browse/MNG-8760

Note that that issue has moved to apache/maven#10312 .

It's odd that such a critical issue (which will block usage in upcoming Java versions, and is already proving irritating in worldwide toolchains with Maven) doesn't even have an indication of whether the issue will be addressed ever.

[garretwilson]

@slawekjaranowski , the Maven team may want to start looking into alternatives to Google Guice, if there is no motivation at Google in making it compliant with upcoming Java versions. You'll notice that Guice 7.0.0 was released over two years ago, with no releases since then. As noted in another discussion, their efforts seem to have shifted to Dagger. The Maven team should probably start thinking of backup plans now, as no one on the Guice team has bothered to give a status and there is no indication that anything will get done.

[cowwoc]

My 2 cents: If you need to support modern versions of Java, steer clear of Google libraries. They have a history of dragging their feet or refusing altogether to fix these kinds of issues. It took us 8 years to convince them to add module-info.java to Guava and honestly I'm surprised it happened in the end: google/guava#2970

[ascopes]

I might be misunderstanding here, but is this not just a case of Google bundling a META-INF/versions/15 directory with a modified version of...

      theUnsafe = UnsafeGetter.getUnsafe();
      Field trustedLookupField = Lookup.class.getDeclaredField("IMPL_LOOKUP");
      trustedLookupBase = theUnsafe.staticFieldBase(trustedLookupField);
      trustedLookupOffset = theUnsafe.staticFieldOffset(trustedLookupField);
      hiddenClassOptions = classOptions("NESTMATE");
      hiddenDefineMethod =
          Lookup.class.getMethod(
              "defineHiddenClass", byte[].class, boolean.class, hiddenClassOptions.getClass());

...that calls the public API for this?

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#defineHiddenClass(byte%5B%5D,boolean,java.lang.invoke.MethodHandles.Lookup.ClassOption...)

Or just that invokes it dynamically if available first, and falls back to a version that works pre-Java 15?

Not sure I understand why this has to be achieved via unsafe reflection if the public API has existed since Java 15?

---

On the topic of moving off of Guice... not sure if that is a simple fix or not since I believe Guice is used between Eclipse Sisu and Plexus within Maven to provide the CDI integration that underpins most of how Maven operates. Agree though that eventually a solution will need to be found once OpenJDK totally rip out sun.misc.Unsafe here.

[trancexpress]

Not sure I understand why this has to be achieved via unsafe reflection if the public API has existed since Java 15?

@ascopes the reflection accesses this: java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP

I'm not sure if there is an API that exposes this Lookup object, its allowedModes are set to Lookup.TRUSTED?...

Naively trying to replace the code results in exceptions:

	Lookup lookup = MethodHandles.lookup();
	Lookup l = lookup.in(hostClass);
	Lookup h = l.defineHiddenClass(bytecode, false, ClassOption.NESTMATE);

Exception in thread "main" java.lang.IllegalAccessException: test.Test3/package does not have full privilege access
	at java.base/java.lang.invoke.MethodHandles$Lookup.defineHiddenClass(MethodHandles.java:2023)
	at test.HiddenClassDefiner.define(HiddenClassDefiner.java:14)
	at test.Test3.main(Test3.java:11)

I checked also the suggested VarHandle (the deprecated API JavaDoc points to VarHandle):

  static {
    try {
      Lookup privateLookup = MethodHandles.privateLookupIn(Lookup.class, MethodHandles.lookup());
	  TRUSTED_LOOKUP = privateLookup.findVarHandle(Lookup.class, "IMPL_LOOKUP", Lookup.class);
      HIDDEN_CLASS_OPTIONS = classOptions("NESTMATE");
      HIDDEN_DEFINE_METHOD =
          Lookup.class.getMethod(
              "defineHiddenClass", byte[].class, boolean.class, HIDDEN_CLASS_OPTIONS.getClass());
    } catch (ReflectiveOperationException e) {
      throw new ExceptionInInitializerError(e);
    }
  }

  public Class<?> define(Class<?> hostClass, byte[] bytecode) throws Exception {
    Lookup trustedLookup = (Lookup) TRUSTED_LOOKUP.get();
    Lookup definedLookup =
        (Lookup)
            HIDDEN_DEFINE_METHOD.invoke(
                trustedLookup.in(hostClass), bytecode, false, HIDDEN_CLASS_OPTIONS);
    return definedLookup.lookupClass();
  }

It requires --add-opens java.base/java.lang.invoke=ALL-UNNAMED:

java.lang.IllegalAccessException: module java.base does not open java.lang.invoke to unnamed module @1dbd16a6
	at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:268)
	at test.HiddenClassDefiner.<clinit>(HiddenClassDefiner.java:21)
	... 1 more

And then still fails with:

java.lang.IllegalArgumentException: illegal lookupClass: class java.lang.invoke.MethodHandles$Lookup
	at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:177)
	at java.base/java.lang.invoke.MethodHandles$Lookup.checkUnprivilegedlookupClass(MethodHandles.java:2416)
	at java.base/java.lang.invoke.MethodHandles$Lookup.newLookup(MethodHandles.java:1547)
	at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:275)
	at test.HiddenClassDefiner.<clinit>(HiddenClassDefiner.java:21)
	... 1 more