Hi, had one of those days, where you spend a lot of time trying to fix something and then find that the solution was much simpler than you realised, but obscured by false leads.
I was reinstalling a old jar file of my own program on my new OpenSuse 15.6 system. When I tried double-clicking from the Desktop, it gave a message that the jar file wouldn’t load and that there may be a problem with the entry point (main class file). After spending some frustrating time trying to fix this, I tried running it from the command line with java -jar and it worked.
I then looked into the desktop launcher code and found that it used a script called jarwrapper with the command line arg %file, which:
(a) fails to properly handle file paths with spaces: and
(b) when it fails, it issues a false message about the main class, rather than the error generated by jar, which would make it obvious that the file path is the problem.
I think I should be reporting this to the developers, but not sure whom. I suspect that the jarwrapper app is part of the JDK installation, but the format of %file may be a KDE matter, or perhaps an OpenSuse matter. Any ideas on what I should do. (I am thinking about trying to rewrite the script and contribute it, but my scripting skills are very limited now and the problem with %file may actually affect other launchers apart from the jarwrapper.)
I deal with these a fair amount at work, I would just utilize a .desktop file and have it invoke the necessary java start command with such a limited use case. The file would go into /usr/share/applications/$APPLICATION_NAME.desktop, then format it with the exec function and Terminal=false so it doesn’t invoke the cli interface. This will allow you to run it from a command context more as a shortcut.
Sample:
/usr/share/applications/com.test.Tailscale-Up.desktop
[Desktop Entry]
Version=1.0
Name=Tailscale Down
Exec=sudo /usr/bin/tailscale down
Icon=/usr/local/share/com.test.Tailscale/tailscale-down.png
Terminal=false
Type=Application
Thanks. I did set up a desktop launcher using the GUI method, but your text-format answer is much more informative and useful. Of course, it would need to be done for every jar file you want to use - which raises the question of whether the OS should automatically use a default script for all files of a particular type which doesn’t read file paths properly and also sends misleading messages. To give an example, I was testing various backup versions of the program stored on a USB stick called STORE N GO. I kept getting a message that there was something wrong with the jar file, when internally jarwrapper was getting the message from ‘java -jar’ that ‘STORE’ was not a java file. It was only when I tracked down jarwrapper, looked at the script and ran it from a command line that it became obvious what was going on.
The concept of an auto tagging launcher creator will probably not go anywhere as it would have an extremely limited use case.
You could easily automate this with a simple bash script though. Just make a for each in present directory and give it a template, just be aware that GDM will display all items in the .desktop format in /usr/share/applications/ even if the application file doesn’t exist.