Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wotaskd and JavaMonitor don't work on Java 17 without manual editing #998

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

timcu
Copy link
Contributor

@timcu timcu commented Oct 23, 2022

This commit sets the JVM options to add-exports sun.security.action to unnamed module by default. Then wotaskd and JavaMonitor will work with Java 17 without having to manually edit Contents/UNIX/UNIXClassPath.txt or similar files for other OSs.

This commit sets the JVM options to add-exports sun.security.action to
unnamed module by default. Then wotaskd and JavaMonitor will work with
Java 17 without having to manually edit Contents/UNIX/UNIXClassPath.txt
or similar files for other OSs.
@timcu
Copy link
Contributor Author

timcu commented Dec 8, 2022

Capturing conversation from Slack

Hugi - will prevent the applications from starting up on JDK 8. I'm quite OK with that, but some others might want to chime

Marc - Huh? wotaskd not being able to start Java 8 applications would definitely be a blocker for us!

Hugi - It would be able to start 8 apps, this only applies to running the wotaskd and javamonitor apps themselves. currently those that run newer jdks have to add parameters in classpath.txt on wotaskd and javamonitor. This change would mean those on older jdks would have to remove parmeters

Tim - So we have to choose between Java 17+ users having to manually add the parameters or Java 8- users having to manually remove the parameters. It only affects new installations of wonder versions of wotaskd and JavaMonitor. Are people still doing new installations with only Java 8 on the server?

Marc - Yes, we do 😉 But I think it's better to go forward, instead of keeping 8 year old technology around for backward compatibility. We can remove those parameters if needed, no problem.

Hugi - Yup. I myself think Wonder should target 17 and workarounds should apply to those on old JDKs. IMHO a sensible action would be to make one last release of Wonder 7, then up the project's major version and continue with JDK 17 as the supported baseline.

Tim - That is probably the kindest solution. It would be harder for a JDK 8 user to debug why wotaskd is not working with the parameters than for a JDK 17 user to debug why wotaskd is not working without the parameters. JDK 8 users are unlikely to be using snapshot versions of wotaskd so once wonder 7.4 is released they can continue to use that release version for years to come and wonder 8 can clearly state that it is not for JDK 8. I would happily use wonder 8-snapshot for wotaskd and JavaMonitor in my new installations before wonder 8 is released.

@spelletier
Copy link
Member

In June 2024, I think we can go forward with this PR, Java 8 is now legacy. Anyone with Java 8 can continue to use a previous build et remove the line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants