Instruct to file an issue at a plugin which uses Java's internal APIs

[opk12]

In the context of #23558 and #21059 (exporting modules to plugins):

If a plugin wants Java's internal APIs, a scary warning dialog says JOSM may work improperly and security.action, but not what to do.

The current workaround is to search Google or file a ticket and learn how to pass --add-exports, also by trial-an-error.

What about instructing the user to file an issue at the defective plugin, that it should not depend on Java's internal APIs, or should make them optional via reflection?

[opk12]

This scary warning is not helpful for an expert mapper unexperienced with Java. Instead it should teach to politely file a ticket at the faulty plugin, which leads to a better mapper and a better plugin in the long term.

[opk12]

Additionally, if JOSM's own jar has Add-Exports: in the MANIFEST.MF as described at https://josm.openstreetmap.de/ticket/21059#comment:10 then users will never have to deal with --add-exports again.

[taylor.smock]

The only way to not need the warning is to move to JPMS and get plugins to move to JPMS (java platform module system).

We are currently blocked by some of our dependencies; they do not offer module information of their own (even Automatic-Module-Name).

Realistically, most people should be using either the JNLP files or the platform specific installers. Those have those JVM arguments added automatically. Only people running the jar files need to worry about adding those JVM arguments.

With that said, if you have a wording suggestion, I am more than willing to hear it.

[GerdP]

I think the warning should say something like
"you are running JOSM with the following args:
java -jar josm-tested.jar
The call should be changed to
java --add-exports [...] -jar josm-tested.jar
to prevent crashes."