[Project A][MacSilicon][Kenneth Seet] Upgrade to Java 17 #6
Conversation
|
@itstrueitstrueitsrealitsreal Thanks for investigating the Mac ARM issue. |
|
@damithc Thanks for pointing that out, it seems I missed that out. I have updated |
|
In addition, I'd like to demonstrate how to see the full list of Java SDKs that SDKMAN offers for download, for others that may not be familiar with its usage.
For any other use cases, you can refer to SDKMAN's documentation or run the command |
| // the user (if looking at the log output) that the said warning appearing in the log | ||
| // can be ignored. | ||
|
|
||
| logger.warning("The warning about Unsupported JavaFX configuration below can be ignored."); |
There was a problem hiding this comment.
@itstrueitstrueitsrealitsreal So, this isn't applicable anymore? As per the comment, this is related to the JavaFX version rather than the Java version.
There was a problem hiding this comment.
@damithc Thanks for pointing that out, I mixed up the JavaFX version and the Java version. I'll revert this change.
There was a problem hiding this comment.
Interestingly, the JavaFX warning doesn't appear in Java 17. So, the comment could be wrong, and this warning should be removed. Worth investigating.
There was a problem hiding this comment.
Looking at the JavaFX 16 release notes linked in the comment, it states that loading JavaFX classes from the classpath instead of modules will log a warning, which contradicts my testing.
This set of release notes also links to this bug report about the above mentioned warning, which aims to document this behavior. However, there are also some interesting comments from users on this issue.
One comment by Gluon co-founder, Johan Vos, summarizing this email thread on the openjfx-dev mailing list stands out:
The mail thread is very interesting. To give my summary of that thread:
end users get errors (
no javafx.graphics module on modulepath) that they don't understand and that seem pointless.there is however a very clear reason on why these warnings are there: JavaFX is designed to work as a set of modules (which of course does not mean that all JavaFX apps need to be modules too).
At this moment, I am not aware of functionality that is broken when using the JavaFX JARs on the classpath, fuelling the assumption that the error is bogus.
It is very likely though that some functionality is broken, or will be broken in the future (due to different access etc in a modular system), hence it is important we recommend users to use the JavaFX artifacts on the modulepath. It will be impossible to support the JavaFX platform jars running on the classpath, due to differences between packages/modules etc (which currently can mainly be overcome with e.g. add-opens etc).
The javafx maven and gradle plugin already do this: if you use those, the javafx artifacts are on the modulepath.
If you still use other tools/IDE's, or manually start JavaFX on the classpath, (a) that should be allowed, but (b) a clear warning is needed that, which explains that you might run into issues (now or later).
This issue will deal with the last point (6b).
In particular, points 4 and 5 stand out, as they highlight that despite the errors seeming unintuitive and unfriendly to beginners, future changes might break the functionalities of JavaFX if users continue using JavaFX JARs on the classpath.
Point 5 is important because it points out that the JavaFX artifacts are already on the modulepath if the JavaFX Maven and Gradle plugins are already used, which is the case for AB3.
The actual email also outlines a workaround for the no javafx.graphics module on modulepath error, which is similar to what is currently being done in AB3 in Main.java.
Taking all this into account, we can either opt to:
Keep the Warning
Keeps the code future-proof:
- Helps protect against future JavaFX updates that might reintroduce issues if classes are not loaded as modules.
- Aligns with community guidance and official documentation, preventing potential future problems.
Maintenance:
- Educates users on the recommended configuration for JavaFX and the significance of module usage.
- Provides clarity in logs, helping users quickly identify and understand the source of the warning.
- Helps to document past design decisions, helping others maintain the codebase in the future.
Remove the Warning
Not useful for current users:
- The current setup with JavaFX 17.0.7 does not produce the warning, indicating the issue may be resolved or the configuration is correct.
- The JavaFX Maven and Gradle plugins already ensure compliance with best practices, making the warning redundant.
YAGNI:
- Removing outdated comments and warnings reduces code clutter and potential confusion for new developers.
- Simplifies logs, making it easier to spot actual issues that need attention.
Minimizes verbosity:
- Reduces the number of warnings which may lead to confusion even though they may not hinder functionality.
I believe that the best course of action is to keep the warning, given that it is in line with the official documentation of the maintainers of JavaFX, and the removal of the warning may lead to confusion down the line as future changes in the plugins bundled with JavaFX, such as Maven and Gradle, may lead to incompatibilities in the future.
There was a problem hiding this comment.
I believe that the best course of action is to keep the warning, given that it is in line with the official documentation of the maintainers of JavaFX, and the removal of the warning may lead to confusion down the line as future changes in the plugins bundled with JavaFX, such as Maven and Gradle, may lead to incompatibilities in the future.
Thanks for the detailed investigation @itstrueitstrueitsrealitsreal
Yes, we can keep it. In that case we should probably revise the text as ... below (if any) can be ignored. (i.e., add (if any)) because the JavaFX warning might not appear in most cases.
damithc
changed the title
|
Tested on Mac Silicon with JDK-FX 17.0.11.fx-zulu, and working. Steps I followed:
Results: Screenshots: |
|
Tested on Mac Silicon with JDK-FX 17.0.11.fx-zulu, and working. Steps and results are identical to above. |
|
Tested on Windows 11, and working. Steps I followed:
|
|
Smoke-tested on Windows 11 using Oracle OpenJDK version 17.0.10 on Windows Powershell Terminal in the same manner as @teoks0199 and ensured all functionalities were in place.
|
|
Tested on Mac Silicon with JDK-FX 17.0.11.fx-zulu, and working. Steps: Screenshots: |
|
Tested on Ubuntu 22.04.4 LTS with zulu jdk 17.0.11. JAR is working fine. Steps followed: Results:
|
|
Tested on MacSilicon with JDK-FX 17.0.11.fx-zulu, and working fine. 
|
|
Tested on Mac (Silicon) using JDK-FX 17.0.11.fx-zulu and working. Downloaded the JAR release, ran the jar file using java -jar MacSilicon-KennethSeet.jar 
|
|
Tested on Linux (Ubuntu 22.04) using OpenJDK 17.0.11. Working. Steps taken:
|
|
Tested on MacSilicon (Sonoma 14.5) using JDK 17.0.11.fx-zulu and working. Steps taken:
|
|
Tested on Windows 11 and working. Steps I followed:
|
| @@ -35,7 +35,7 @@ public static void main(String[] args) { | |||
| // the user (if looking at the log output) that the said warning appearing in the log | |||
| // can be ignored. | |||
|
|
|||
| logger.warning("The warning about Unsupported JavaFX configuration below can be ignored."); | |||
| logger.warning("The warning about Unsupported JavaFX configuration below (if any) can be ignored."); | |||
There was a problem hiding this comment.
@itstrueitstrueitsrealitsreal Can you send a separate PR for this?
|
Closing, as the migration was done in fe805d8 |
Description
This pull request includes updates to the documentation and the
gradle.ymlfile to reflect the migration of the project to Java 17. Additionally, various JDK distributions were tested for compatibility with our codebase.Environment Setup
Issues Encountered
Running AB3 on ARM64 Systems:
As an M1 Mac user, I encountered compatibility issues with certain Java versions. Non-supported SDKs would lead to a
java.lang.UnsatisfiedLinkErrorindicating an 'incompatible architecture'—my machine uses ARM64, but the application required X86-64.To resolve this, it's necessary to install an ARM64 compatible SDK with JavaFX bundled. However, constantly switching between different SDKs for various needs can be cumbersome.
During CS2103 in AY23/24 Semester 2, I discovered SDKMAN!, a UNIX command-line tool that facilitates switching between Java SDK versions. This tool proved essential as I needed Java 17 for teaching CS2030 and Java 11 for CS2103.
For my system, only the JDK versions
17.0.11.fx-zuluand17.0.11.fx-librcawere compatible.Suggestion for Future Iterations
Considering the growing popularity of ARM64 machines, documenting the use of SDKMAN! for managing and switching Java SDKs could be beneficial for future courses.