| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
As I feared, if ASM doesn't know about the bytecode version, it will not allow it. I will investigate if there is a way to programmatically determine the highest version it supports because I really want to eliminate this manual code. |
Sorry, something went wrong.
|
Latest changes seem to work but I want to add a test to verify that it is picking the latest version. |
Sorry, something went wrong.
The ASM library hard codes a set of known bytecode versions, which can only be programmatically queried with reflection. This change uses reflection to pick the correct bytecode version for the JVM we are running on, falling back on the highest version supported by ASM if the JVM version is newer than that. Fixes #9443
…bytecode.version=8) See jruby/jruby#9444 - likely unintentionally removed the mapping for `8`.
| Back | FazBrowse Home | New Git URL |
The ASM library hard codes a set of known bytecode versions, which frequently forces us to select an earlier version than the JVM we are running on. This change makes that byte code version open-ended, decoupling us from the ASM supported bytecode versions.
This is somewhat experimental, since we do not know how ASM will react if the JDK version is much newer than it's known byte code versions. If this patch does not work, we will fall back on updating ASM to latest and dealing with and updating our version calculation in the future.
Fixes #9443
Update: as suspected, ASM will not permit us to use bytecode versions newer than it supports, so I have made an additional change to limit the open-endedness of this to just the values the current ASM version supports.