Document limitations of CGLIB proxy class generation in JPMS module setups

[xenoterracide]

Document limitations of CGLIB proxy class generation in JPMS module setups

[philwebb]

Some debugging shows that the classloader used when trying to enhance org.example.bugspringsecurityjpms.BugSpringSecurityJpmsApplication is the AppClassLoader, despite the RestartClassLoader being set here.

[philwebb]

@xenoterracide If you're not directly calling bean methods in your @Configuration class you can try doing @SpringBootApplication(proxyBeanMethods = false) so that the proxy isn't created.

[jhoeller]

I've added a note to the reference documentation as well as corresponding hints to the exceptions thrown from CGLIB's ReflectUtils and specifically from ConfigurationClassEnhancer. I hope this improves the guidance when running into this.

There is no chance of this getting revised at the Java platform level. This is part of the encapsulation design, preventing certain internal access to core Java classes to begin with. While there is an escape hatch on the classpath, there is intentionally none for the module path.

[jhoeller]

Please understand that JPMS simply does not allow for defining new classes in unrelated ClassLoaders: There is intentionally no Java platform API that lets us do this. This is not a CGLIB incompatibility or a legacy warning that we don't care about, it is rather a fundamental consequence of the module system being designed to prevent such runtime definitions in distinct ClassLoaders.

As for that fallback code path in ReflectUtils, we just retain that for compatibility with --add-opens=java.base/java.lang=ALL-UNNAMED. This will always fail in a strict module system setup but only after having tried the JDK 9+ Lookup.defineClass API first. Unfortunately Lookup.defineClass only works for the original ClassLoader, not for a separate ClassLoader that we may want to define the proxy class in. This prevents certain kinds of use cases that used to work fine in a classpath setup, e.g. proxies for certain core Java types.

There is one escape hatch in a Spring setup: SmartClassLoader.publicDefineClass which the Boot RestartClassLoader implements. Such explicit support for externally provided class definitions is the only way to make a separate ClassLoader work in a JPMS setup at all. If spring-projects/spring-boot#40434 reveals anything concrete that can be improved for that escape hatch, I'm happy to consider it. Beyond that, I'm afraid we are not able to do anything about the fundamental limitations in the platform module system.

[wilkinsona]

@jhoeller this isn't a Devtools problem as the attached sample isn't using Devtools and RestartClassLoader isn't involved. Unfortunately, that means that there's no opportunity in Boot for us to do anything that requires a custom class loader.

I think this is the same as or very similar to the problem reported in spring-projects/spring-boot#26578. I've just closed that issue as there's nothing we can do in Boot as we don't have any control over the class loader.

I think the proxyBeanMethods = false workaround, either on @SpringBootApplication or @Configuration, is the best we can offer at the moment for this particular case. It may be that this just needs to be documented as a possible escape hatch for the fundamental limitations of the platform module system. For other Framework features that rely on proxying, such as the use of AOP seen in spring-projects/spring-boot#26578, there may be no workaround.

[jhoeller]

@wilkinsona thanks for the update, I'll turn this issue into a documentation ticket then. There is indeed nothing we can do in scenarios where we don't control the ClassLoader, and I'm not expecting any Devtools-driven refinement on the core side either.

[philwebb]

FWIW the sample in spring-projects/spring-boot#26578 does use devtools but for some reason the RestartClassLoader isn't being used when the enhancer runs.

[xenoterracide]

questions:

1. Has anyone whined at Java about this? I'd do it but I A don't know what I'm talking about, and B it'd be a lot more meaningful coming from Spring which is huge.
2. Is it possible to auto-magically detect being run on the module path and either disable the feature auto-magically or in addition to documentation throw a better error pointing to the documentation/fix?
3. Tangent, I notice the error itself is around java.lang classes, whenever I've defined a @Bean of type String (etc), that's had problems where I've had to disable the proxy on it anyways... from the discussion I'm certain that avoiding that wouldn't fix anything but maybe it could be avoided?

[xenoterracide]

long term then, it might be a good idea to extract the "cglib" package to another jar and not make it available in spring boot by default (like v4). just my opinion, so it can be more of an auto-detected feature... or see if there are other strategies to do this that could be employed.

Honestly, I don't think I'll be missing anything? time will tell I guess... never really liked some of that proxy magic in configuration classes myself.

Thanks for the documentation!