Graal support - Simplifies native image manipulation when bytebuddy as a dependency #1586
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… java5 to support the prefined classed feature of native-image
dreamlike-ocean
changed the title
|
Good point and there's nothing in the dispatcher class files that would need a different version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When a library A depends on bytebuddy and a program B depends on A, before compiling B with graalvm's native image, the user needs to use the java agent to generate predefined classes files to support the dynamic class generation in the JavaDispatcher of bytebuddy in A. Then the user needs to ensure that Runtime $Version is initialized during build time to ensure that the predefined classes of graal function normally.
If any step is missing, it will start generating the java5 version of the proxy class after native without corresponding to the product of predefined classes.
Even after successfully native according to the above process, when the user upgrades the jdk, they have to regenerate the predefined classes that A depends on. I think this should be the responsibility of the author of library A.
Therefore, this PR will fix the corresponding bytecode generated version to jdk5, so that the author of lib A can directly package the corresponding'net/bytebuddy/utility/Invoker $Dispatcher ' `s predefined classes files into the jar, thus reducing the difficulty of native