JDK 24 - sun.misc.Unsafe has been called by lombok.permit.Permit

[bjornharvold]

Getting this warning when building with Maven v3.9.9 and JDK 24.

[WARNING] WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe:objectFieldOffset has been called by lombok.permit.Permit
WARNING: Please consider reporting this to the maintainers of class lombok.permit.Permit
WARNING: sun.misc.Unsafe:objectFieldOffset will be removed in a future release

[rzwitserloot]

... and the people who fucked this up is OpenJDK and not us. We're aware, we won't forget.

As we have a few avenues we can take to 'start' lombok as part of the compilation process, the proper description of the issue is larger than these warnings and the solution isn't set in stone yet: having a ticket for it feels like more a burden than a useful thing, hence, closing it.

[victorwss]

@rzwitserloot Can Permit guess the offset somehow without having to use objectFieldOffset?

Perhaps, with some serialization trickery onto AccessibleObject or maybe relying on some trial-and-error?

Or perhaps, just detect which VM is being used and choose a number accordingly, crossing-fingers that unknown future versions don't change it away from the last known versions.

[rzwitserloot]

@victorwss I'm not sure what good this would do. Yes, the warning would go away for objectFieldOffset but I'm pretty sure there would be more warnings for other methods we can't 'guess' the result for. Any attempt we write to guess at oFF's result is always risky (in that there is no spec so anything we write, we're just guessing it'll apply for all JDK releases, all versions, all platforms, all situations, all phases of the moon - this is by definition not possible, so that commit has a large 'lets pray its right' factor. This is not worth it, if the only benefit is getting rid of a warning - a warning that will likely appear anyway for other calls, or in near-future JDK versions).

The solution is to not use the permit system at all because OpenJDK is pretty heckbent on ensuring that cannot be done the way we are doing it.

[prdoyle]

What does Permit do? Is there a way I can opt out, or is it too fundamental?

[Rawi01]

@prdoyle You can probably disable the warning or just ignore it. At some point the api gets removed and you have to adjust your build configuration. Lombok does not need sun.misc.Unsafe, we only use it to make it way easier to setup a lombok build.

[prdoyle]

Thanks @Rawi01 and @rzwitserloot. Is the larger issue/discussion being tracked anywhere?

[prdoyle]

For anyone else seeing this problem with Gradle, I suppressed the warning like this:

tasks.withType(JavaCompile).configureEach {
	options.forkOptions.jvmArgs << '--sun-misc-unsafe-memory-access=allow'
}

[lprimak]

@Rawi01 I am getting this error too, and feels "icky" to disable the warning.
I looked quickly at the code and it looks like only Eclipse is using the Permit class.
I am not using Eclipse at all but just building in maven.

You mention something like:

At some point the api gets removed and you have to adjust your build configuration. Lombok does not need sun.misc.Unsafe

Can you elaborate a bit on that? What needs to be done to "adjust build configuration" to remove the warning and for Lombok to not need to use Permit / Unsafe? Can this be done today or is it something that needs to be done on Lombok side?

Thank you again for the wonderful product!

[lprimak]

Rawi, can you please elaborate how to adjust build configuration to avoid this warning?
Thank you!

[lprimak]

@Rawi01 Any updates you can shed a light on this will be appreciated. Thank you!

[Rawi01]

Add --sun-misc-unsafe-memory-access=allow to your compiler arguments and the warning should disappear

[lprimak]

Add --sun-misc-unsafe-memory-access=allow to your compiler arguments and the warning should disappear

Ahhh... That's not what I meant :)

Lombok does not need sun.misc.Unsafe, we only use it to make it way easier to setup a lombok build.

This is what I am trying to understand. How do I actually remove Unsafe usage as opposed to hiding it with a command-line flag?

What option to do use to remove the Unsafe usage, not hide it?

Thanks again!

[mikomikotaishi]

I'm getting this error when trying to compile with Gradle, which I presume is related.

[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] FAILURE: Build failed with an exception.
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * What went wrong:
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Execution failed for task ':app:compileJava'.
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > java.lang.ExceptionInInitializerError
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * Try:
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Run with --scan to get full insights.
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Get more help at https://help.gradle.org.
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * Exception is:
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:compileJava'.
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:130)
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:293)
...
[org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: java.lang.NoSuchFieldException: com.sun.tools.javac.code.TypeTag :: UNKNOWN
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at lombok.permit.Permit.getField(Permit.java:144)
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at lombok.javac.JavacTreeMaker$SchroedingerType.getFieldCached(JavacTreeMaker.java:171)
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at lombok.javac.JavacTreeMaker$TypeTag.typeTag(JavacTreeMaker.java:259)
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   at lombok.javac.Javac.<clinit>(Javac.java:187)
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]   ... 52 more
[ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] 
[ERROR] [org.gradle.internal.buildevents.BuildResultLogger] 

I guess this is specifically with trying to access TypeTag.UNKNOWN.