Timeline for Unsafe deprecation

[cushon]

5821ccc

Cannot define class using reflection: As of Java 26, using Unsafe is disabled by default, set net.bytebuddy.safe to true if you want to use the JVM's internal unsafe API even though it will become unsupported in the future and should be replaced by injection using method handles: net.bytebuddy.dynamic.loading.ClassInjector$UsingLookup

This was also mentioned in the release notes for 1.18.19

Disable use of Unsafe by default when Java 25 or newer is discovered.

Is there a timeline for when this functionality will become unsupported by bytebuddy?

I noticed this because it affects some code that is using ClassLoadingStrategy.Default.INJECTION to create proxies for classes in java.base that it isn't possible to get a private lookup for.

[raphw]

As for java.base, you can also use a class loader wrapper. If you do not use an explicit strategy, this is already what Byte Buddy is doing. For Java agents, there is a workaround using Instrumentation to use jdk.internal.misc.Unsafe which preserves today's behaviour.

In what context do you have an issue without using Unsafe? All scenarios that I know of should be solvable.

As for the timeline: Oracle has announced it, and it already generates warnings on any JVM launch. I would be surprised if it is still possible on the LTS after Java 25.

[cushon]

Thanks! The usage here was a utility for creating proxies for arbitrary instances. It's old code I didn't write, but migrated to bytebuddy from cglib following your blog post here.

I'm investigating using the default strategy for load for system classes, and will see how that goes and report back if there are any cases I can't figure out how to address without Unsafe.

As for the timeline: Oracle has announced it, and it already generates warnings on any JVM launch. I would be surprised if it is still possible on the LTS after Java 25.

Understood, we've been following the deprecation and are preparing for the removal from a future JDK release. For bytebuddy are you expecting to follow the timeline of the removal of Unsafe from the JDK, or is there a possibility you'd remove support from bytebuddy earlier before it's removed from the JDK?

[cushon]

I'm investigating using the default strategy for load for system classes

I think I've been able to avoid relying on Unsafe. The main issue I ran into was generating subclasses of classes loaded by the bootstrap or platform classloader.

• For non-agents, I generated the subclass into a different package, and then used ClassLoadingStrategy.UsingLookup. I think that's similar to what mockito is doing with org.mockito.codegen.InjectionBase

• For agents, I think AgentBuilder.InjectionStrategy.UsingInstrumentation is unconditionally using reflection / Unsafe for classes not in the bootstrap classloader:

  byte-buddy/byte-buddy-dep/src/main/java/net/bytebuddy/agent/builder/AgentBuilder.java

  Lines 4587 to 4591 in 7dd9a0d

  	public ClassInjector resolve(@MaybeNull ClassLoader classLoader, @MaybeNull ProtectionDomain protectionDomain) {
  	return classLoader == null
  	? ClassInjector.UsingInstrumentation.of(folder, ClassInjector.UsingInstrumentation.Target.BOOTSTRAP, instrumentation)
  	: UsingReflection.INSTANCE.resolve(classLoader, protectionDomain);
  	}

  Would it make sense for UsingInstrumentation.resolve to check if UsingReflection is available and try ClassInjector.UsingInstrumentation instead in that case?

[raphw]

For agents in particular, there is still a hole in the support by the JVM for not using unsafe as method handles rely on a loaded class which is not available while instrumenting. You can use instrumentation to open the internal Unsafe to an agent: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-dep/src/main/java/net/bytebuddy/dynamic/loading/ClassInjector.java#L2304

This will not trigger a warning as you are pretending to be a JDK class.

[cushon]

Thanks! I confirmed that Unsafe is working for me for the agent where I encountered this.

Do you think it'd still make sense to add a check to AgentBuilder to see if UsingReflection is available and fall back to something else? Do you think that agents will be able to use whatever the JVM does internally indefinitely, or at least after the Unsafe deprecation?

[raphw]

Could do, but there is no good fallback I could think of. From JDK9, only method handle lookups work, but those need an anchor class. Do you have a suggestion?

[cushon]

I had wondered about ClassInjector.UsingInstrumentation.of(folder, ClassInjector.UsingInstrumentation.Target.SYSTEM, instrumentation), which seemed to work for one of the cases I was looking at, or does that not make sense?

[raphw]

It works for the system class loader, indeed. The boot loader is however the one class loader that cannot be reached through reflection, so it would solve a special case somewhat, but fail for non-system loaders. I wonder if this really solves anything since agent authors would need to take care of this mechanism anyways to write generic agents. I am worried that this might create a sense of false security if this was the default.

[cushon]

Got it, thanks. I can see it could be better for agent authors to have to make an explicit choice instead of having something that only works some of the time.

[ilgrosso]

Just FYI we recently switched from Spring Boot 4.0.7 (ByteBuddy 1.17.8) to Spring Boot 4.1.0 (ByteBuddy 1.18.10).

When running with JDK 27-ea, the same code fails with

java.lang.UnsupportedOperationException: Cannot define class using reflection: As of Java 26, using Unsafe is disabled by default, set net.bytebuddy.safe to true if you want to use the JVM's internal unsafe API even though it will become unsupported in the future and should be replaced by injection using method handles: net.bytebuddy.dynamic.loading.ClassInjector$UsingLookup
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$Initializable$Unavailable.defineClass(ClassInjector.java:555)
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection.injectRaw(ClassInjector.java:364)
	at net.bytebuddy.dynamic.loading.ClassInjector$AbstractBase.injectRaw(ClassInjector.java:202)
	at net.bytebuddy.dynamic.loading.ClassInjector$AbstractBase.inject(ClassInjector.java:190)
	at net.bytebuddy.dynamic.loading.ClassLoadingStrategy$Default$InjectionDispatcher.load(ClassLoadingStrategy.java:248)
	at net.bytebuddy.dynamic.TypeResolutionStrategy$Passive.initialize(TypeResolutionStrategy.java:101)
	at net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:7725)
	at org.apache.wicket.proxy.bytebuddy.ByteBuddyProxyFactory.lambda$createOrGetProxyClass$0(ByteBuddyProxyFactory.java:119)
	at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:172)

with Spring Boot 4.1.0, while runs fine with Spring Boot 4.0.7 (giving the expected warning message).

Adding -Dnet.bytebuddy.safe=true does not seem to help, so we went ahead and defined a Maven profile to keep using ByteBuddy 1.17.8 with Spring Boot 4.1.0.
Now it's working well.