Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Refactor Servlet API and JDBC plugins to use a MethodHandles-based advice dispatching approach #1090
Refactor Servlet API and JDBC plugins to use a MethodHandles-based advice dispatching approach #1090
Changes from 15 commits
285b488
10c1c6b
6681d2e
cb11904
554bf88
e06680c
06375d8
ea9db90
47a25f4
84ba2b6
a9a4611
8287bcb
daa8e29
edf8ffe
a8a08e9
c0f3750
7810901
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part may be done prematurely - it will be invoked when the bytecode-injection candidate class is found, however the helper may depend on other classes that are not yet loaded and loading them here is a side effect. The use of reflection means completion of the helper classes linkage, which kind of guarantees that. Related errors will be very hard to detect.
I think that this part should be done lazily, meaning - keep a mapping between the helper class name and the helperCL and do the actual registration only upon first invocation of the injected method. Should be a lot safer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lazily injecting the helper classes has the downside that we wouldn't be able to leverage an upcoming feature in Byte Buddy. This feature would inject an
INVOKEDYNAMIC
instruction to call the helper method: raphw/byte-buddy#830 (comment)This avoids the overhead of having to look up the method handle from a map.
However, there are a few things we can do to make this safer:
@RegisterMethodHandle
-annotated methods.getMethods
instead ofgetDeclaredMethods
: avoids resolving types of all parameters of non-public methods. So we could make methods with problematic signatures private or package-private.bootstrap
method, I think we'd be able to get the method handles without having to use reflection. We'd need to do some testing but I suspect we'll need a fallback for Java 7 that does not rely onINVOKEDYNAMIC
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it something we should rely on? And won't we have to do some adjustments anyhow?
The nature of these problems is that they are very setup-dependant, so there are not "problematic signatures" per se. In most cases it will work, but somewhere (eg some module-dependency systems) these side effects may cause a lookup of a type that is not yet available.
Bottom line- it is safer and if the effort is not big, I think it worth it (as the effort to debug even a single related problem could be bigger). However, if the effort is substantial, or if you think it will require a rework effort in the foreseeable future - let's merge as is and rethink later if needed. It's really your call, either way is fine for me.