-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document limitations of CGLIB proxy class generation in JPMS module setups #32671
Comments
Some debugging shows that the classloader used when trying to enhance |
@xenoterracide If you're not directly calling bean methods in your |
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 There is one escape hatch in a Spring setup: |
@jhoeller this isn't a Devtools problem as the attached sample isn't using Devtools and 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 |
@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. |
FWIW the sample in spring-projects/spring-boot#26578 does use devtools but for some reason the |
questions:
|
I've added a note to the reference documentation as well as corresponding hints to the exceptions thrown from CGLIB's 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. |
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! |
it would appear that these problem also disappear with |
arguably a duplicate of #24922 but since that wasn't fixed and actually causes real errors when using JPMS. It's not a warning. From the looks of it you're seeing if you can proxy
java.lang
bug-spring-framework-jpms-32671.tar.gz
blocks #18079
side comment: can we please stop the pattern of closing with "it's just a warning"? especially if it's a warning from java which means it's someone's error.
The text was updated successfully, but these errors were encountered: