Arch Linux User Repository

Hello, yes I have seen the jar loader :) Alright, I understand and I haven't many choices for packaging a native launcher for launchpad so I created a simple sh script 🙃 Let's keep it that way yup

@Quentium thanks for the comment.

We have implemented native executable binary that will load jd-gui jar compared to sh script you provided.

Now, it's a debate to which one is "better", I personally believe that it is not necessary to go via shell just to launch a Java jar file, and such a app(jar) should launch as fast as possible(without any overhead), and with minimal dependencies.

Regarding jd-gui.c(current jar loader), all it's issues have been resolved. Will it have issues in future, of course. Will we fix them, ofcourse.

Unless current loader is misbehaved I think we should remain just as is.

fyi: sh script provided by ~Quentium:

#!/bin/sh
exec java -jar /opt/jd-gui/jd-gui.jar "$@"

Hello, I am the maintainer of JD-GUI. Thanks for updating to the latest version, I'm glad arch is having this fork available thanks to you.

I know this jar binary was often complicated to bundle, that's why the deb was never published to launchpad by myself because I struggled to automate it.

With the new update, I managed to do that correctly and support all JRE. If you prefer, you can use the launchpad deb package here https://launchpad.net/~quentiumyt/+archive/ubuntu/jd-gui/+files/jd-gui_1.7.3-1+noble_amd64.deb

I hope it will help you to make a pkgbuild with less workarounds now :)

Less runtime dependencies

The diff against 1.7.1-2 does not show any removed dependencies.

Lower startup overhead(CPU time, memory footprint, disk access, etc)

It's only a GUI application with less than 1s startup time though, not a tool that will be frequently called. Also, did you actually benchmark it?

shell script have hardcoded limit of 10 arguments.

Really? Where is this limit set?

If a native launcher is really important, it could be merged into the upstream. AUR is not intended to provide new features. I as a user want to review a simple shell script instead of a C source file, not to mention that it changed six times without a new upstream version.

• Less runtime dependencies
• Lower startup overhead(CPU time, memory footprint, disk access, etc)
• shell script have hardcoded limit of 10 arguments.
• No script interpretation on process startup.
• last, when using ps, top, htop or similar tools you can't easily find process when run from script.

There are more, but those are what I think of at this moment.

I'm wondering how building a custom native launcher is better than using a shell script.

@Musikolo, I will upgrade the launcher soon so the package will:

• Not require JDK, but JRE only.

• Do a runtime detection of openjdk version(as you requested).

I will need to check jd-gui project for supported Java versions.

@bokic, I've noticed you added jdk21-openjdk as a dependency and linked it to that version. I tested the app with Java 17 and it worked well for me. So, if there is a minimum JDK required version, I think a better approach would be to set java-runtime=17 as a dependency. Also, you should revert to the previous path setup you had with /usr/lib/jvm/default-runtime/ rather than enforcing version 21 with /usr/lib/jvm/java-21-openjdk/.

I hope it helps.

Regards.

Following

Available Java environments:
  java-11-openjdk (default)
  java-8-openjdk

@bokic I have openjdk 8, 11, and 23 installed. 8 is default.