fix: admin console setup page: check JRE version with Runtime.Version #2721
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @stokito, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
This pull request addresses a bug in the admin console setup page related to JRE version checking, specifically for versions like 23-ea. It replaces the previous method of parsing the java.version system property with Runtime.version() for more accurate JRE version comparison. This change ensures compatibility checks work correctly, particularly with newer OpenJDK versions.
Highlights
- Bug Fix: Corrects JRE version comparison on the admin console setup page.
- Version Compatibility: Ensures compatibility checks function correctly with OpenJDK versions like
23-ea. - API Usage: Replaces
System.getProperty("java.version")withRuntime.version()for JRE version detection.
Changelog
- xmppserver/src/main/webapp/setup/index.jsp
- Replaced the old JRE version check using
System.getProperty("java.version")with a new check usingRuntime.version(). - Introduced
Runtime.Version.parse("11")to define the minimum required Java version. - Used
compareToto accurately compare the current JRE version against the minimum required version.
- Replaced the old JRE version check using
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Trivia time!
When was Java 11 released?
Click here for the answer
Java 11 was released on September 25, 2018.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request fixes a bug related to JRE version checking in the admin console setup page by using Runtime.version() for comparison. The change appears to be straightforward and addresses the reported issue with OpenJDK versions.
Merge Readiness
The code change appears correct and addresses the bug as described. I am unable to approve the pull request, and users should have others review and approve this code before merging. Since there are no critical or high severity issues, the pull request seems ready to be merged after another review.
| // Check for min JRE requirement | ||
| Runtime.Version MIN_JAVA_VERSION = Runtime.Version.parse("11"); | ||
| jreVersionCompatible = MIN_JAVA_VERSION.compareTo(Runtime.version()) <= 0; |
There was a problem hiding this comment.
Consider extracting the MIN_JAVA_VERSION constant to a more global scope if it's used elsewhere, or making it a static final field within the JSP if it's specific to this page. This would improve readability and maintainability.
| Runtime.Version MIN_JAVA_VERSION = Runtime.Version.parse("11"); | ||
| jreVersionCompatible = MIN_JAVA_VERSION.compareTo(Runtime.version()) <= 0; |
There was a problem hiding this comment.
When a user runs Java 8, this will fail, since the Runtime API was introduced in Java 10.
I suspect other stuff will also fail in Java 8 too though... @guusdk ?
|
Yes, but the min jdk was raised to 11 in openfire v4.9 and then to 17 in v5.0
|
|
By that measure, why have the check at all? |
|
This is pre-instalation check for the min JDK |
|
So we should make sure it errors gracefully on Java 8? |
|
if the OF was compiled with -source 11 level then the class files may have a new bytecode instructions and when starting on older JRE the java.lang.UnsupportedClassVersionError may occur. It may be need to test if you can get to the page in the JRE8 |
|
That would be interesting: can we get to this page using JRE8? If so, then I believe that we should generate a 'proper' error message, rather than having an UnsupportedClassVersionError or something similar. As Openfire has been using Java 8 for years, I do suspect that a lot of people will still use Java 8 when installing Openfire. Let's give them a clear error condition, rather than a weird stack trace. What was the original problem with |
Split from #2563 to simplify of review.
Fixed a bug that I had on
23-eaOpenJDK version.Use Runtime.version() to compare JRE version. It works correctly now.