Skip to content
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

Inject generated property accessor classes via ReflectUtils.defineClass(…) [DATACMNS-1080] #1525

Closed
spring-projects-issues opened this issue Jun 2, 2017 · 1 comment
Assignees
Milestone

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Jun 2, 2017

Jens Schauder opened DATACMNS-1080 and commented

DATACMNS-1079 disables the ClassGeneratingPropertyAccessorFactory for Java 9, which is unfortunately, because we'll lose the nice performance characteristics it has. So should look for an alternative that basically does what the current version does, but in a way that works for Java 9


Issue Links:

Referenced from: pull request #234

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jun 20, 2017

Juergen Hoeller commented

This looks like the same problem as with CGLIB which got addressed by Rafael Winterhalter in CGLIB 3.2.5 a while ago: cglib/cglib@d6fe1d8

Essentially, the immediate solution is to use Unsafe.defineClass instead of making the protected ClassLoader.defineClass accessible. It sounds awkward but it actually cleanly works since Unsafe remains accessible by default even on JDK 9. However, Unsafe.defineClass is marked as deprecated in JDK 9, with MethodHandles.Lookup.defineClass as the official replacement: https://bugs.openjdk.java.net/browse/JDK-8181442. So for Spring Data Kay without any JDK 6 compatibility baggage, it might be better to go with that right away, even if MethodHandles.Lookup.defineClass can still only be called reflectively there.

As an alternative, you could also define those generated classes in a custom child ClassLoader which can cleanly access the protected defineClass method internally. This is the approach that SpEL's compiler mode uses: It works fine there since the generated expressions are internally managed and never leak to the user, so they can be consistently generated and retrieved from an internal child ClassLoader

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants