Upgrade Java 17 references to Java 21#21
Conversation
- Remove Java 17 Maven profile from pom.xml (no longer needed since Java 21 is minimum) - Update validateJavaVersion() in OpenmrsUtil.java to check for Java 21 minimum - Update README.md to reflect Java 21 as minimum required version Co-Authored-By: unknown <>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| String majorStr = version.contains(".") ? version.substring(0, version.indexOf('.')) : version; | ||
| majorVersion = Integer.parseInt(majorStr); | ||
| } catch (NumberFormatException e) { | ||
| // If we can't parse the version, skip validation | ||
| return; |
There was a problem hiding this comment.
🟡 Version validation bypassed for EA/pre-release Java versions due to hyphen in version string
When java.version is a pre-release string without a dot (e.g., "21-ea", "17-ea+25"), the code at line 1082 takes the else branch (version has no .), setting majorStr to the full string "21-ea". Integer.parseInt("21-ea") then throws NumberFormatException, and the catch block at line 1084-1086 silently returns, skipping validation entirely.
Root Cause and Impact
The parsing logic only splits on . but does not account for the - separator used in early-access and pre-release Java version strings (e.g., "17-ea", "21-ea+25").
For a version like "17-ea" (which should be rejected since 17 < 21), the flow is:
version.contains(".")→falsemajorStr = version→"17-ea"Integer.parseInt("17-ea")→ throwsNumberFormatException- Catch block returns without throwing → validation skipped
This means an unsupported Java version like 17-ea would pass the check, potentially leading to runtime failures later. The fix should strip the pre-release suffix before parsing, e.g.:
String majorStr = version.split("[.\\-+]")[0];| String majorStr = version.contains(".") ? version.substring(0, version.indexOf('.')) : version; | |
| majorVersion = Integer.parseInt(majorStr); | |
| } catch (NumberFormatException e) { | |
| // If we can't parse the version, skip validation | |
| return; | |
| String majorStr = version.split("[.\\-+]")[0]; | |
| majorVersion = Integer.parseInt(majorStr); | |
| } catch (NumberFormatException e) { | |
| // If we can't parse the version, skip validation | |
| return; | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Description of what I changed
Updated all references to Java 17 (and legacy Java 8) to reflect Java 21 as the minimum required Java version:
pom.xml: Removed thejava17Maven profile. Since Java 21 is now the minimum supported version, the Java 17–specific profile (which overrode mockito-core and byte-buddy versions) is no longer needed. Thejava21andjava24profiles remain.api/src/main/java/org/openmrs/util/OpenmrsUtil.java: RewrotevalidateJavaVersion()to enforce Java 21 as the minimum. The old implementation used a regex (1\\.[0-7]\\.(.*)) that only caught pre-Java 8 legacy version strings. The new implementation parses the major version number fromjava.versionand rejects anything below 21.README.md: Updated the prerequisites section to state Java 21 as the minimum JDK version (was Java 8).Reviewer notes
validateJavaVersion()returns silently ifjava.versioncannot be parsed (catchesNumberFormatException). Consider whether this should throw an error instead.System.getProperty("java.version")is assumed non-null. This is standard JVM behavior but worth noting.JavaVersionTestonly tests the happy path (current JVM >= 21 passes). No negative-path tests (e.g., mocking a version string like"17.0.1") were added.Issue I worked on
see https://issues.openmrs.org/browse/TRUNK-
Checklist: I completed these to help reviewers :)
mvn clean packageright before creating this pull request and added all formatting changes to my commit.Link to Devin run: https://app.devin.ai/sessions/36cfa93e393c4a90a23eee6bcb245bdf
Requested by: @dillonvargo