Illegal reflective access warning for ExecutorBeanPostProcessor proxy creation

[pandrez]

Affects: 5.1.7.RELEASE

---

On a Spring Boot 2.1.5.RELEASE application with Spring Cloud Greenwich.SR1 running with OpenJDK 11.0.2, we get the following warning:

WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils (file:/.../org/springframework/spring-core/5.1.7.RELEASE/spring-core-5.1.7.RELEASE.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
	at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:525)
	at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:363)
	at org.springframework.cglib.proxy.Enhancer.generate(Enhancer.java:582)
	at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:110)
	at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:108)
	at org.springframework.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
	at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
	at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:134)
	at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:319)
	at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:569)
	at org.springframework.cglib.proxy.Enhancer.createClass(Enhancer.java:416)
	at org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:57)
	at org.springframework.aop.framework.CglibAopProxy.getProxy(CglibAopProxy.java:205)
	at org.springframework.aop.framework.ProxyFactoryBean.getProxy(ProxyFactoryBean.java:378)
	at org.springframework.aop.framework.ProxyFactoryBean.getSingletonInstance(ProxyFactoryBean.java:330)
	at org.springframework.aop.framework.ProxyFactoryBean.getObject(ProxyFactoryBean.java:254)
	at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.getObject(ExecutorBeanPostProcessor.java:199)
	at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.getProxiedObject(ExecutorBeanPostProcessor.java:186)
	at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.createAsyncTaskExecutorProxy(ExecutorBeanPostProcessor.java:169)
	at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.wrapAsyncTaskExecutor(ExecutorBeanPostProcessor.java:147)
	at org.springframework.cloud.sleuth.instrument.async.ExecutorBeanPostProcessor.postProcessAfterInitialization(ExecutorBeanPostProcessor.java:92)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:429)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1782)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:593)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:515)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
	at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:277)

[jhoeller]

This seems to be a side effect of #22416 where we only use the new JDK 9+ defineClass API if the ClassLoader matches... and in this case, the target class seems to come from the system class loader whereas we want to define the proxy in the application's class loader. Let's see whether we can refine our condition to include such cases as well.

[RobMaskell]

Also seeing this, hopefully same issue but posting the log just in case. Spring 5.1.8, openjdk 11

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.springframework.cglib.core.ReflectUtils (file:/home/robm/.gradle/caches/modules-2/files-2.1/org.springframework/spring-core/5.1.8.RELEASE/37fd45c92cfd05b9ad173ee1184ec4221e0f931f/spring-core-5.1.8.RELEASE.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 org.springframework.cglib.core.ReflectUtils
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

[jhoeller]

For the time being, these warnings should go away when starting the JVM with --illegal-access=deny since we are going to fall back to the JDK 9+ defineClass API even without a ClassLoader match.

[xak2000]

The same issue (different class loaders) is reproduced when spring-boot-devtools is on classpath.

• contextClass.getClassLoader() returns jdk.internal.loader.ClassLoaders.AppClassLoader
• loader is equal to org.springframework.boot.devtools.restart.classloader.RestartClassLoader

So, contextClass.getClassLoader() == loader is false.

In my case it was triggered when contextClass was com.zaxxer.hikari.HikariDataSource and com.zaxxer.hikari.HikariConfig. No other classes triggered this path (Classic option: protected ClassLoader.defineClass method).

JDK 11, Spring 5.2.3.RELEASE, Spring Boot 2.2.3.RELEASE

[oraculo-nl]

this might help #22814 (comment)

[jhoeller]

Aside from several available refinements in recent releases, this is superseded by efforts around #22814 and #26403, to be picked up in corresponding Boot releases.