Arch Linux

Issue screenshot can be found here: https://josm.openstreetmap.de/attachment/ticket/21649/screenshot.png

Runtime flag required by upstream is:

--add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED

The fix did not fully solve the issue.
See https://josm.openstreetmap.de/ticket/21989 .
See also https://josm.openstreetmap.de/browser/josm/trunk/native/linux/tested/usr/bin/josm for a known good start script (Debian).

Additional comment: I've got a ticket that makes the upstream start script more agnostic (see https://josm.openstreetmap.de/ticket/22088 ). Is there anything missing from your perspective that would make it easier to use the upstream start script?

Can you please revert https://github.com/archlinux/svntogit-community/commit/ef93f762186a93115ac574fc708d13f6bf57cb8f? Specifically with respect to the `JOSM_ARGS` environment variable -- it does not work on machines using Java 8 as the default.

Also, adding `install -Dm755 $pkgname/native/linux/tested/usr/bin/josm "${pkgdir}"/usr/bin/josm` should remove the need for https://github.com/archlinux/svntogit-community/blob/packages/josm/trunk/PKGBUILD#L43-L56 (and the need to try to manually work around differences in Java versions).

Hi Taylor,
thanks a lot for helping us out!

I've tried your fixes and I get the error:
Error: Unable to access jarfile /usr/share/josm/josm.jar

The file does not exist, the correct path seems to be:
/usr/share/java/josm/josm.jar

Does this need to get fixed in josm or our package? What is your suggestion?

@jlichtblau Would it be okay for you, if I co-maintain the package? Where do you get the changelog from and why is it even in our svn? Is it important?

No problem.

The script reads environment variables, so setting `JOSM_PATH=/usr/share/java/josm/josm.jar` in the environment (or in `/etc/default/josm`, sourced via `. "/etc/default/${JOSM_VERSION}"`) should work.

The path to JOSM is set with `JOSM_PATH="${JOSM_PATH:-/usr/share/${JOSM_VERSION}/${JOSM_VERSION}.jar}"`

The other env setting of interest might be for javafx, `JAVAFX_HOME="${JAVAFX_HOME:-/usr/share/openjfx/lib}"`.

I tried to make the script as configurable as possible for downstream users when I was fiddling with it a few months back.

@NicoHood: I finally sat down and figured out everything that needed to be done for the Arch package. It wasn't as easy as I thought -- Arch puts the JavaFX modules in with the rest of the JVM modules, which leads to interesting error messages if JAVAFX_HOME is set to the path where the JavaFX modules are.

Anyway, if the attached patch is applied, JOSM will start and run properly.

Ping

Had to delete `JOSM_ARGS="--add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED"` from `/etc/conf.d/josm` to make it work again.

Hi! Sorry for getting really late to this bug.

@Taylor: Why do we need to set the JOSM_PATH via sed in the startup script. Isnt adding it in the config better? That sounds more correct to me, however it does not work at all. I guess the reason is, that previously this config was loaded with the custom startup script. Doesnt it make sense to keep it?
```
[ -f /etc/conf.d/josm ] && . /etc/conf.d/josm
```

With your other fix I get the error at startup:
ls: cannot access '/usr/lib/jvm/default-runtime/lib/javafx*.jar': No such file or directory

This turns out, because the sed command is not written correct and the newline will expand. This is what the script contains:
```
JAVAFX_HOME="$(ls /usr/lib/jvm/default-runtime/lib/javafx*.jar | tr "
" ":" | sed 's/.$//')"
```

If I remove that, no error will occur. So is this "hack" even needed???

You have also added java-openjfx as a new dependency. Is that required? For me josm also starts without that dependency.

> Why do we need to set the JOSM_PATH via sed in the startup script. Isnt adding it in the config better?
I'm not a disto packager, but I would think that it would be better to have sane defaults, in case the user deletes the config file.

> With your other fix I get the error at startup:
That is funny. It worked for me when I tested. Does `/usr/lib/jvm/default-runtime/lib/` exist? The only reason for the `JAVAFX_HOME="$(ls [...])"` was because I couldn't just set the `JAVAFX_HOME` variable to the directory; there were some issues with double loading modules.

> If I remove that, no error will occur. So is this "hack" even needed???
JavaFX is _not_ required by JOSM itself. Plugins may require JavaFX. Of note, there is the `javafx` plugin which pretty much just adds an audio player and some utility classes, and then Microsoft Streetside which uses JavaFX for cubemapping 360 images.

> You have also added java-openjfx as a new dependency. Is that required? For me josm also starts without that dependency.
So the answer is _technically_ no, it is not required for base functionality, but it is required for some plugins.

For me the startup script from the package currently in the repos is also not working, I get the following error:

```
Using /usr/bin/java to execute josm.
Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.web not found
```

It works if I uncomment the last sed line in the PKGBUILD (the newline is expanded, but this works regardless.)

The error (`ls: cannot access '/usr/lib/jvm/default-runtime/lib/javafx*.jar': No such file or directory`) is caused by the failing glob. One can simplify that to a simple echo (as the glob does the expansion on itself), paired with `shopt -s noglob` there will only be an empty string if there are no matching files.
Thus

sed -i '5 aJAVAFX_HOME="$(shopt -s nullglob && echo /usr/lib/jvm/default-runtime/lib/javafx*.jar | tr " " ":")"' "${pkgdir}/usr/bin/josm"

in the PKGBUILD works also but should not generate an error (and fall back to the default in the start script, but I do not know if that causes any problems)

Maybe java-openjfx should at least be added to optdepends?

Sorry for coming back late here and thanks for all the answers.

@taylor.smock
Why did you comment that line?

sed -i 's/--module-path ${JAVAFX_HOME} //' "${pkgdir}/usr/bin/josm"

@malteger thanks for that fix!

I've updated the package once more with those fixes. I will try to update the version itself now.

I think I was trying to say `If the JavaFX modules were automatically loaded by the JVM, we could just remove the `--module-path ${JAVAFX_HOME}` line, here is the sed command`