[PATCH] Sanity check JVM arguments on startup

[taylor.smock]

This is mostly so we stop getting tickets where any of the following are true:

• User is running 32 bit JVM on 64 bit OS
• User is missing a required JVM argument
• User is running an unsupported version of Java (this is intended for when we increment the min Java version; I want to compile a minimal set of classes with the previous min version of Java in order to give the user better instructions on what to do).

[taylor.smock]

@anonymous: I don't think I would classify this as a blocker. If you have specific reasoning as to why it should be a blocker, please put that in a comment.

[gaben]

I patched r18924 and tried with Java 7:

$ java -version
openjdk version "1.7.0_352"
OpenJDK Runtime Environment (Zulu 7.56.0.11-CA-linux64) (build 1.7.0_352-b01)
OpenJDK 64-Bit Server VM (Zulu 7.56.0.11-CA-linux64) (build 24.352-b01, mixed mode)

$ java -jar josm-custom.jar 
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/openstreetmap/josm/gui/MainApplication : Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:808)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:448)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:65)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:349)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:348)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:430)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:329)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:588)

so not sure about the last wish is possible with the current approach.

[taylor.smock]

I have to modify build.xml for (3). Specifically, I'm going to need to compile a minimal subset of classes with Java 8 when we move to Java 11+.
At a minimum:

• MainApplication
• Utils
• PlatformHook

I'll have to experiment to get the minimum classes to show the user the warning message.

[taylor.smock]

It looks like the JVM tries to load all classes, so I'm not going to be able to have a minimal subset of classes compiled with Java 8. What I can do (and will) following the 24.01 release is apply the patch.

EDIT: We'll still compile for Java 8, but won't allow users past the nag screen until they update to Java 11+. And then we can move to Java 11/17/21.

[GerdP]

Tried to apply the patch but got this:

c:\josm\core>svn patch f:\dwnload\temp\23355.2.patch
U         src\org\openstreetmap\josm\gui\MainApplication.java
U         src\org\openstreetmap\josm\gui\MainInitialization.java
U         src\org\openstreetmap\josm\tools\PlatformHook.java
U         src\org\openstreetmap\josm\tools\PlatformHookOsx.java
U         src\org\openstreetmap\josm\tools\PlatformHookUnixoid.java
U         src\org\openstreetmap\josm\tools\PlatformHookWindows.java
svn: E721392: Can't open 'C:\josm\core\test\unit\org\openstreetmap\josm\tools\svn-49B406D0': Die Datei oder das Verzeichnis ist beschädigt und nicht lesbar.

The file name is probably a temp file and changes each time when I try.

[taylor.smock]

I have no clue what is going on there.
I usually use curl ${URL} | patch -p1, but I just tried in a clean JOSM directory with svn patch 23355.2.patch, and that worked.

A couple of questions:

1. Is your C partition full/almost full? That might be causing the corruption/unreadable file warnings.
2. Have you tried rebooting? I don't think this will help, but I've been surprised before.
3. How old is your hardware? I hope it isn't failing (in this case, it would be the hard drive that might be failing).

[GerdP]

Had the same ideas, I also updated svn. I bought the PC a few days ago because my old one broke down and really was old, the SSD is brand new, my installation is that from an image I made a few days before the hardware broke. Everything else runs well, it's just this patch which causes trouble. I'll try to find out why...

[taylor.smock]

Good luck. I hope you figure out what is going on.

my installation is that from an image I made a few days before the hardware broke

Does it happen with a new checkout of JOSM? I doubt that will fix the issue, but it is possible that some files were corrupted from the old hardware.

[GerdP]

It works on a clean checkout of JOSM on a different new drive and I have problems deleting the old directory on C:
So, problem is here and I hope it's gone with the fresh checkout now.

[GerdP]

With the patch applied I've compiled with JDK 17. When I start JOSM with just

java -jar dist\josm-custom.jar

a popup is shown that tells me that some settings are missing.

Missing JVM Arguments: '--add-exports=java.base/sun.security.action=ALL-UNNAMED'
Missing JVM Arguments: '--add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED'
Missing JVM Arguments: '--add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED'

When I press Cancel the startup continues. Is that the intended behaviour?
I think it would be good if JOSM could show and log the full wanted startup command.
With JRE 8 the startup gives

C:\josm\core>java -jar dist\josm-custom.jar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/openstreetmap/josm/gui/MainApplication has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)

[taylor.smock]

I made a change to build.xml to build for Java 11. You can revert the build.xml changes to see what happens.

I was playing around with compiling specific files for Java 8, but (as noted in comment:6) so we could have a "fallback" for old Java versions, but it seems like that won't work.

[taylor.smock]

When I press Cancel the startup continues. Is that the intended behaviour?

Yes; the missing JVM arguments are mostly an informational warning (and something we can point at when closing tickets that are missing the arguments).

I think it would be good if JOSM could show and log the full wanted startup command.

This is probably doable; I would just have to get the current command used to start JOSM.

[GerdP]

When starting JOSM in Eclipse with the Java 8 configuration it stops after showing the new popup, no matter what button I press.

[taylor.smock]

That was by design -- see PlatformHook.java#L411.

It specifically changes the title of the dialog from JOSM may work improperly to JOSM will be unable to work properly and will exit.

EDIT: I probably ought to remove the 'Cancel' button from the dialog.

[GerdP]

My problem is: I cannot yet start JOSM in Eclipse with the never configurations like "c:\josm\core\tools\eclipse\JOSM (Java latest).launch"
It only works when I remove this part:

--module-path C:\Java\javafx-sdk-16\lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web

I that what I am supposed to do? Or do I have to get a proper javafx-sdk?

[taylor.smock]

You can try with just --add-modules java.scripting,java.sql.

The JavaFX options are pretty much only needed if the JavaFX plugin is installed. I'm hoping we can get rid of the --add-modules bit when we move to Java 11+.

[GerdP]

OK, good enough for me, those modules are found without extra files.

[GerdP]

I just noticed a log message

java.lang.ClassNotFoundException: com.sun.deploy.config.BuiltInProperties

which is produced by org.openstreetmap.josm.tools.Utils.getJavaExpirationDate()
I see this message for Java 8 and 17, so I wonder if the corresponding code is useless nowadays?

[taylor.smock]

I think that is only useful for Oracle Java JREs. I haven't touched one of them for quite some time.

I think we can remove it once we move to Java 11+, since there will be no Oracle JREs available. Maybe someone will install the Oracle JDK? But that won't be the vast majority of our users, and someone who has installed the Oracle JDK when we are pointing people at Azul's distribution probably don't need the Java out of date nag.

[GerdP]

OK, thanks, didn't think about different JRE providers.

[taylor.smock]

In 18985/josm:

Fix #23355: Sanity check JVM arguments on startup

See #17858: JOSM will no longer continue running if the user is on an unsupported
Java version (for this commit, older than Java 11; message indicates Java 17).
This does update the link for Azul from Java 17 to Java 21 as well.

In order to (hopefully) reduce confusion, the webstart and Java update nags will
also be reset in the event that JOSM will exit due to old Java versions. This is
mostly so that users will get the messages to update to OpenWebstart or the
appropriate Java link for their platform and architecture.

Additionally, this will (hopefully) reduce the number of tickets we have to close
due to missing JVM arguments by informing users of the missing arguments at startup.

[GerdP]

The start configuration JOSM (Java latest).launch for Eclipse are missing some of the arguments:

--add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED 
--add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED 
--add-exports=java.base/sun.security.action=ALL-UNNAMED 

Attached is a patch to my current version using jdk 17. Not sure which of the changes are special, so maybe only the above should be added.
Edit: The same entries are missing in "JOSM (Java 11).launch"

[GerdP]

When I start JOSM from the command line with

java -jar dist\josm-custom.jar

I see the this popup:

Pressing Esc stops JOSM, pressing Enter also stops JOSM. Only when I use the mouse to click the "Continue" button the startup continues, so I think the icon in the "Continue" button is wrong.

[taylor.smock]

What icon do you think would be better for continue? We use that same icon for "ok". I mean, continue allows the user to keep using JOSM after the nag.

The start configuration JOSM (Java latest).launch for Eclipse are missing some of the arguments: [...] so maybe only the above should be added.

Yeah, its just the org.eclipse.jdt.launching.VM_ARGUMENTS bit that matters. I'll fiddle with the eclipse launch commands.

[anonymous]

I cannot start JOSM with latest JNLP. Using Java 21 now...

[GerdP]

What icon do you think would be better for continue?

For me, the icon represents "press Enter". Maybe the JOSM icon for continue?

[taylor.smock]

Replying to anonymous:

I cannot start JOSM with latest JNLP. Using Java 21 now...

@anonymous: Are you using ​OpenWebStart or Oracle Webstart? If the latter, it is Java 8 only. If the former, it should just work.
If it isn't working using OpenWebStart, please attach logs.

[taylor.smock]

Replying to GerdP:

What icon do you think would be better for continue?

For me, the icon represents "press Enter". Maybe the JOSM icon for continue?

Fair enough. I always thought of that icon as "continue" (since that is pretty similar to "ok").

[gaben]

Replying to taylor.smock:

@anonymous: Are you using ​OpenWebStart or Oracle Webstart? If the latter, it is Java 8 only. If the former, it should just work.
If it isn't working using OpenWebStart, please attach logs.

Oopsie, that was me. Using Azul IcedTea-Web, so that's the issue, thanks.

[gaben]

New issue with OpenWebStart and Java 21:

Missing JVM Arguments: --add-exports=java.base/sun.security.action=ALL-UNNAMED

[taylor.smock]

I saw that when I was double-checking to see if something was broken using OWS.

It turns out that --add-exports=java.base/sun.security.action=ALL-UNNAMED is --add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop under OWS. I just have to change the check from Collection#contains to something a bit more robust.

[taylor.smock]

@GerdP: Do you like ("apply") better?

[GerdP]

Also OK for me, I suggested the JOSM icon above.

[taylor.smock]

I think I missed something somewhere or I'm misunderstanding something.

What icon did you suggest? You mentioned "ok", except that is ("ok").

[taylor.smock]

Update eclipse launch files

[taylor.smock]

@GerdP: Can you let me know if the patched launch files work? I was going to set up an Eclipse workspace on my machine, but I cannot install the IvyDE plugin anymore (the update site no longer exists). I think I'm going to have to prioritize #8269 more now.

[GerdP]

Replying to taylor.smock:

I think I missed something somewhere or I'm misunderstanding something.

What icon did you suggest? You mentioned "ok", except that is ("ok").

I meant the apply icon is good for me, I suggested to use the JOSM icon (the one with the map and the pencil in upperleft corner of this wiki) in comment:29

[GerdP]

Replying to taylor.smock:

@GerdP: Can you let me know if the patched launch files work? I was going to set up an Eclipse workspace on my machine, but I cannot install the IvyDE plugin anymore (the update site no longer exists). I think I'm going to have to prioritize #8269 more now.

Probably not on my machine because I don't have javaJX installed.

[taylor.smock]

I meant the apply icon is good for me, I suggested to use the JOSM icon (the one with the map and the pencil in upperleft corner of this wiki) in comment:29

Ah. I misread your comment. I thought you were talking about an image for "continue", not .

Probably not on my machine because I don't have javaJX installed

Fair enough. Removing the javafx bits should work, and I don't have JavaFX globally installed either.

[GerdP]

Removing the javafx bits should work, and I don't have JavaFX globally installed either.

Yes, I'd prefer to have the minimal set of needed parameters, but besides that the patch works (after pointing to the correct JRE)

[taylor.smock]

after pointing to the correct JRE

I'm checking to see if it is possible to have a generic "correct" JRE, but if not, I'll just commit what I had.

[GerdP]

With JOSM (Java latest).launch, it is probably not possible unless you want to force a specific JRE configuration as in JOSM (Java 11).launch

[taylor.smock]

In 18986/josm:

See #23355: Sanity check JVM arguments on startup

Change the icon for Continue and be a more lenient when comparing expected JVM
arguments against actual JVM arguments.

This additionally updates the Eclipse launch files.

[anonymous]

Java 8 only

[anonymous]

This is how it looks with only Java 8.
Maybe the "Radio Buttons" should be removed, they are not remembered.

[anonymous]

Replying to taylor.smock:

I was playing around with compiling specific files for Java 8, but (as noted in comment:6) so we could have a "fallback" for old Java versions, but it seems like that won't work.

I don't think it's a good idea to force users into an upgrade path if they don't want to upgrade. The main problem is that JOSM is still on a "rolling release" model not allowing for multiple branches to support different JDK versions. This is a historical issue: If josm used git, it could simply branch instead of giving up old JDK completely.

You could then port features not strictly dependent on "latest and greatest" JDK between branches. Of course, this will also imply that branches may divert if new features are introduced to non-master branches, so you'd have, by convention, to carefully watch, that these are only commited to in a backport-from-master manner:

To not be flooded with tickets and get into a support nightmare, devs could still opt to accept new tickets for the master branch only. But, of course, this would only make sense at all if there are devs on the team that are willing to occasionally contribute backports - and maybe a motivation to do so, read: reliable numbers on how JDK/JRE versions are distributed among the user base; this is not easy to source, because you'd have to implement a privacy-violating call-home feature to get these statistics)

JOSM is a software actually used, not a university test project and constantly calling for system updates just to run it is not really user friendly. And if APIs or e.g. authentication endpoints change it is not truely a choice anymore by the user whether to keep running an older version.

[taylor.smock]

I don't think it's a good idea to force users into an upgrade path if they don't want to upgrade

They can stay on older JOSM versions

If josm used git, it could simply branch instead of giving up old JDK completely.

This would be a maintenance burden; we are lucky to have two active maintainers a month. Sometimes we are really lucky, and have more. :)
In short, I don't think we could realistically support multiple branches. Especially if we have to backport.

JOSM is a software actually used

Yes, and we have to actually maintain it. A lot of our dependencies have updates that are Java 11+, and they are not maintaining Java 8 versions.

constantly calling for system updates just to run it is not really user friendly

We have installers that bundle the requisite Java version. You could use those. Or just use an older version of JOSM.

[stoecker]

Replying to anonym:

I don't think it's a good idea to force users into an upgrade path if they don't want to upgrade.

We force nobody. Everybody is free to run updated software or not. Anybody not wanting to update can simply keep any older version.

The main problem is that JOSM is still on a "rolling release" model not allowing for multiple branches to support different JDK versions. This is a historical issue: If josm used git, it could simply branch instead of giving up old JDK completely.

This is no "historical issue", but intentional design. JOSM does no backports and no releases, but develops a constantly usable application and marks certain versions as more stable. A very successful development model for more than 15 years now.

You could then port features not strictly dependent on "latest and greatest" JDK between branches. Of course, this will also imply that branches may divert if new features are introduced to non-master branches, so you'd have, by convention, to carefully watch, that these are only commited to in a backport-from-master manner:

I always wonder why other people know better than us how this software needs to be developed. My suggestion: Feel free to provide your own Java 8 version of JOSM. As you know: it's OpenSource. Nobody prevents you to take the last Java 8 version and backport any new changes to this version.

read: reliable numbers on how JDK/JRE versions are distributed among the user base

If you'd at least would have tried to research before, then you'd have found JOSM usage statistics in the ticket system. We know what our users use with an accuracy good enough to base decisions on that.

JOSM is a software actually used, not a university test project and constantly calling for system updates just to run it is not really user friendly. And if APIs or e.g. authentication endpoints change it is not truely a choice anymore by the user whether to keep running an older version.

If after 8 years requesting to update Java to a more recent version (that's the time since r10579 which was the last Java 7 release) is constantly calling for OS upgrades for you, then I maybe should look what bugs I can exploit on your IP. Your system must have thousands of security holes.

[anonymous]

I get the same message as in comment 26.
https://josm.openstreetmap.de/ticket/23355#comment:26

If I select "Show this dialog agaon the next time", JOSM starts.
But if I select "Do not show again (remembers choice)" and confirm, JOSM no longer starts.

What are these additional JVM parameters good for? I have been using JOSM for over 10 years and never needed them.

Revision:18997

Identification: JOSM/1.5 (18997 en) Linux Ubuntu 23.10

Java version: 20.0.2+9-Ubuntu-0ubuntu123.04, Private Build, OpenJDK 64-Bit Server VM

[anonymous]

To be clear, JOSM never starts again after I select "Do not show again (remembers choice)" and confirm.
I had to manually delete the following lines from preferences.xml:

<tag key='message.sanityCheckFailed' value='false'/>
<tag key='message.sanityCheckFailed.value' value='2'/>

[taylor.smock]

In 18998/josm:

See #23355: Don't store stop answers for startup sanity check

[GerdP]

That change didn't help, the program stills stores the values in preferences. Besides that I'd prefer that the "don't show again" button works instead of ignoring it.

[taylor.smock]

That's funny. It worked for me when I was testing it.

EDIT: And the Don't show again button was working. Its just that the user hit an option that would always close JOSM.

[GerdP]

Just to make clear: I press the continue button, not stop.

[GerdP]

If you really want to nag users to set the additional parameters I see no need for the checkboxes.

[stoecker]

I agree with GerdP. As these options are helpful, but JOSM works without, the dialog should be able to be ignored.

[taylor.smock]

It was supposed to be able to be ignored. The major unique thing with this dialog is we don't want to save the stop answer.

It looks like I messed up and misunderstood the way ExtendedDialog works. In order for the saved value to be present in getValue, showDialog must first be called. I've got a fix locally that I'm validating.

[anonymous]

Replying to taylor.smock:

Its just that the user hit an option that would always close JOSM.

No, that's not true.

"Show this dialog again the next time" -> "Continue": JOSM starts
"Do not show again (remembers choice)" -> "Continue": JOSM no longer starts.

So I clearly did not select an option that always closes JOSM.

[taylor.smock]

That is what I get for skimming the problem as I multitask.

[stoecker]

Replying to taylor.smock:

That is what I get for skimming the problem as I multitask.

Humans can't really multitask. Only preemptive multitasking is possible and processing state preserving at the context switches is lacking a lot. ;-)

[taylor.smock]

I know. In my defense, I'm usually "multitasking" when I'm waiting for ant clean dist pmd checkstyle to finish running. Of course, that means I need to remember what I was doing if something fails, but that is usually the last thing I run prior to commit.

[taylor.smock]

In 18999/josm:

See #23355: Ensure that the dialog has read the preference key for the sanity check

[sebastic]

Replying to taylor.smock:

In 18985/josm:

Fix #23355: Sanity check JVM arguments on startup

See #17858: JOSM will no longer continue running if the user is on an unsupported
Java version (for this commit, older than Java 11; message indicates Java 17).
This does update the link for Azul from Java 17 to Java 21 as well.

In order to (hopefully) reduce confusion, the webstart and Java update nags will
also be reset in the event that JOSM will exit due to old Java versions. This is
mostly so that users will get the messages to update to OpenWebstart or the
appropriate Java link for their platform and architecture.

Additionally, this will (hopefully) reduce the number of tickets we have to close
due to missing JVM arguments by informing users of the missing arguments at startup.

This commit bumped the dependency for the Debian package to java11-runtime, but the Java <= 10 JREs are still used if detected in the josm launcher.

You'll likely want to remove those JREs too, e.g. with this patch:

linux/latest/usr/bin/josm-latest

@@ -23 +23 @@
         # LTS versions in decreased order
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-$ARCH/bin/java"
-        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-8-openjdk/bin/java /usr/lib/jvm/java-8-openjdk-$ARCH/bin/java"
         # Released versions in decreased order
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-18-openjdk/bin/java /usr/lib/jvm/java-18-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-16-openjdk/bin/java /usr/lib/jvm/java-16-openjdk-$ARCH/bin/java"
@@ -31 +30 @@
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-14-openjdk/bin/java /usr/lib/jvm/java-14-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-13-openjdk/bin/java /usr/lib/jvm/java-13-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-12-openjdk/bin/java /usr/lib/jvm/java-12-openjdk-$ARCH/bin/java"
-        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-10-openjdk/bin/java /usr/lib/jvm/java-10-openjdk-$ARCH/bin/java"
-        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-9-openjdk/bin/java /usr/lib/jvm/java-9-openjdk-$ARCH/bin/java"
         # Development version(s)
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-19-openjdk/bin/java /usr/lib/jvm/java-19-openjdk-$ARCH/bin/java"
     fi

linux/tested/usr/bin/josm

@@ -23 +23 @@
         # LTS versions in decreased order
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-$ARCH/bin/java"
-        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-8-openjdk/bin/java /usr/lib/jvm/java-8-openjdk-$ARCH/bin/java"
         # Released versions in decreased order
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-18-openjdk/bin/java /usr/lib/jvm/java-18-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-16-openjdk/bin/java /usr/lib/jvm/java-16-openjdk-$ARCH/bin/java"
@@ -31 +30 @@
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-14-openjdk/bin/java /usr/lib/jvm/java-14-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-13-openjdk/bin/java /usr/lib/jvm/java-13-openjdk-$ARCH/bin/java"
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-12-openjdk/bin/java /usr/lib/jvm/java-12-openjdk-$ARCH/bin/java"
-        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-10-openjdk/bin/java /usr/lib/jvm/java-10-openjdk-$ARCH/bin/java"
-        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-9-openjdk/bin/java /usr/lib/jvm/java-9-openjdk-$ARCH/bin/java"
         # Development version(s)
         JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-19-openjdk/bin/java /usr/lib/jvm/java-19-openjdk-$ARCH/bin/java"
     fi

[aceman]

Hi. What do these JVM arguments (exports) actually do? Why are they needed? I ran JOSM just fine for years without any visible problems. Maybe they should be explained to the user.

Second, the Stop button in the dialog is using the wrong translation, the one for the "Stop" traffic sign. They need to be decoupled in the string resources file (​https://translations.launchpad.net/josm/trunk/+pots/josm/sk/+translate).

[taylor.smock]

@sebastic: Done in r19018.

@aceman: See #21059. If you run JOSM without plugins, you should be "fine". And when we are able to create a module-info.java file, I think we can drop the VM arguments. But the module-info.java file is a little ways out (some of our dependencies haven't modularized yet).

[aceman]

I have been running with many plugins enabled for a long time. So what do these arguments add?

[stoecker]

In 19019/josm:

see #23355, wrong translation

[aceman]

Replying to stoecker:

In 19019/josm:

see #23355, wrong translation

Thanks.