fix(base-option): reimplement JDKVersion on top of Runtime.Version - #106
Merged
Conversation
This file contains hidden or 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
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.
JDKVersion.of("25.0.4.1")did not compare as newer thanJDKVersion.of("25.0.4"). The hand-written parser only ever populatedmajor,minor, andsecurityfrom the first three dotted elements and dropped any fourth element, so a four-segment version such as an Azul-style$PATCHrespin was parsed as if it were25.0.4andcompareToreturned0.The fix reimplements
JDKVersionas a thin wrapper around a single parsedRuntime.Version, which models the full dotted version-number sequence and provides a correct ordering.compareTo,equals,hashCode,toString, and every accessor (major(),minor(),security(),build(),pre(),optional(),version(),isModular()) now delegate to the wrapped value. A newruntimeVersion()accessor exposes it directly. This replaces roughly 330 lines of position-scanning parser and its parallel field set.Modern strings are passed straight to
Runtime.Version.parse(String). Legacy pre-Java-9 strings (those starting with1.) are first normalized: a regex remaps1.xto the modern scheme, dropping the leading1., folding the_updatesegment into the dotted version number (so1.8.0_292becomes8.0.292), and turning-bNNinto+NN. Trailing.0elements, whichRuntime.Versionrejects but legacy strings and some tooling emit, are stripped, so25.0.4.0still normalizes to and compares equal to25.0.4.equalsis now defined ascompareTo(other) == 0andhashCodereturnsversion.hashCode(). This is consistent becauseRuntime.Version.compareTocompares the same four components (version,pre,build,optional) thatRuntime.Version.equalsandhashCodeuse, and because normalization guarantees no instance retains trailing zero elements, so any two instances that compare equal have identical component lists.This also drops the
base-foundationdependency frombase-option(bothpom.xmlandmodule-info.java), sinceStringswas its only use and no other module in the repository consumesJDKVersion.Behavior changes for callers:
toString()now returns the normalized modern-scheme form rather than a custom rendering;get()still returns the raw input, and forcurrent()that raw value now comes fromRuntime.version()instead of thejava.versionsystem property; andof(String)now throwsIllegalArgumentExceptionfor null, blank, or unparseable input rather thanNoSuchElementExceptionor a bareRuntimeException.