EclipseLinkASMClassWriter.getLatestOPCodeVersion was emitting an incorrect warning and picking the oldest Java bytecode version if encountering an unsupported Java version (Bugzilla #579391) #18
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.
Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=579391
SCENARIO:
Using Eclipselink MOXy (using latest eclipselink-asm) on Java 18
ACTUAL RESULT:
When using EclipseLink MOXy 2.7.8 or 2.7.10 on Java 18, the following warning is printed to stderr:
org.eclipse.persistence.internal.libraries.asm.EclipseLinkASMClassWriter getLatestOPCodeVersion
WARNING: Java SE '18' is too old.
EXPECTED VALUE:
It should be printing:
WARNING: Java SE '18' is not fully supported yet. Report this error to the EclipseLink open source project.
CONSEQUENCE:
This bug also causes EclipseLink ASM to set version to 1.7 (so presumably will generate Java 1.7 bytecode rather than Java 17 bytecode)
The code is using a TreeMap for "versionMap" but then using "lastKey()" as if TreeMap preserved insertion order (or used numerical order), rather than natural string ordering, and lastKey returns "9" since the String "9" > "17"
DESCRIPTION OF CHANGE:
The fix for this is to switching from TreeMap to LinkedHashMap, which preserves insertion order.
In addition to this bug, the Map construction code is pointlessly creating an anonymous class and storing the Map in the heap forever, whereas "versionMap" could be constructed within getLatestOPCodeVersion and populated with calls to .put, removing the need for that anonymous class (and saving wasted heap space as an added benefit)
Additionally, "version" could be made static so that this computation only happens once per class load (and to reduce the number of times the warning might be printed to stderr)