Live data from Hacker News

JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

jdeploy.com

81–90 of 133 posts

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#81
post #70

Earlier quoted context omitted.

FWIW, there's JetBrains's JetBrainsRuntime project [1] containing Swing patches for eg HiDPI support and other things. Haven't worked with it, nor do I have a stake in it; just mentioning it because JetBrain are one of the few companies delivering kick-ass, commercially successful, mainstream desktop software using Java/Swing today. [1]: https://github.com/JetBrains/JetBrainsRuntime

Is there a reason these are not getting backported to OpenJDK? I know that jetbrains do contribute a bit, but I feel like their model of having way out of date jdks shipped (offering worse performance then available) is not a good one. (They just recently switched to 11, and was still using the old concurrentms GC, over which G1 runs circles, let alone ZGC)

Its possible to run IntelliJ with a Java 17 runtime now, not out of the box but there is a download somewhere.

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#83

Earlier quoted context omitted.

This looks very cool. What Java framework(Swing, FX etc) would you recommend for a desktop Java app?

There's an exciting desktop port of https://developer.android.com/jetpack/compose done by Jetbrains: https://github.com/JetBrains/compose-jb

I was thinking that this combo can really change the native desktop development landscape, it's still too early to tell but if you can solve development speed, performance, looking good and easy deployment in one stack it would really improve over Electron based apps.

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#84
post #23

Earlier quoted context omitted.

There's an exciting desktop port of https://developer.android.com/jetpack/compose done by Jetbrains: https://github.com/JetBrains/compose-jb

It is exciting but even less there than JavaFX unfortunately. That's the problem with most UI systems, they evolve really fast in the beginning and show great promises, then the real difficulties arise and you have users that start to want a stable API.

The thing is that Compose is becoming the de facto UI toolkit for Android, and there is A LOT of really smart people working on it (both at Google and Jetbrains).

Maybe I'm over-hyping it, but I really doubt there has been a UI toolkit with that much work behind in a long time (Maybe Cocoa and one of the last 3 iterations of UI toolkit on Windows had that many work hours, but Cocoa does not work in all OS and the Windows ones well ... :shrug:)

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#85
post #14

Earlier quoted context omitted.

Nice to see some freshness pushed into the officially dead model of sharing a JRE between applications instead of going through the pains of the jlink route which seems a bit heavy for many use cases. Assuming I'd rather self-host instead of hitching a ride on npm - could it it still be useful, as a cross-platform bundle maker? What are the single points of failure for the curated JRE procurement? Is it npm, is it jd…

> Assuming I'd rather self-host instead of hitching a ride on npm - could it it still be useful, as a cross-platform bundle maker? I've seen some interest for self hosting, so it will likely be added. In an earlier iteration (I've been at this for a couple years), it was self hosted, but I found that npm brought a lot to the table and simplified things, so I focused on that. > What are the single points of failure fo…

Side note / shout out to Azul for being just great. Their technical support (even while just evaluating Zing) has been excellent and their free Zulu offering is a breeze to install (Debian here).

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#86
post #70

Earlier quoted context omitted.

FWIW, there's JetBrains's JetBrainsRuntime project [1] containing Swing patches for eg HiDPI support and other things. Haven't worked with it, nor do I have a stake in it; just mentioning it because JetBrain are one of the few companies delivering kick-ass, commercially successful, mainstream desktop software using Java/Swing today. [1]: https://github.com/JetBrains/JetBrainsRuntime

Is there a reason these are not getting backported to OpenJDK? I know that jetbrains do contribute a bit, but I feel like their model of having way out of date jdks shipped (offering worse performance then available) is not a good one. (They just recently switched to 11, and was still using the old concurrentms GC, over which G1 runs circles, let alone ZGC)

It is absolutely awful by default; IntelliJ apps are slow to the point of being unusable out of the box. The good news is that it is easily fixed (at least for my use case). I have tinkered a bit and running them on JDK16 or later, with JATOC has been a life-saver for me the past year, and reduced my paying subscription to an act of charity.

"Develop with pleasure" is well and truly dead until they make the out-of-box experience FAST.

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#87

Earlier quoted context omitted.

I considered that. The approach I'm taking was inspired by the way that Chrome creates app bundles for PWAs. > What happens when someone publishes some malware application using their wrapped and noterized installer The installer application simply installs the app. It doesn't in itself run any of the app's code. The installed app doesn't need to be codesigned and notarized like it would if you had just downloaded it…

> The installer application simply installs the app. It doesn't in itself run any of the app's code. The installed app doesn't need to be codesigned and notarized Wait, then doesn't that mean Apple's intent there is broken? I mean if you can bypass its controls on installing unsigned apps by merely wrapping an unsigned (possibly malicious) app in a signed installer, then what's the point?

Very naive question but is it different from what npm, pip, etc. let you do already? Does the app installed this way get more permissions coming from a signed installer? I'm not familiar with OSX security model.

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#88
Nice, I’ve recently gone through setting up a build process with jpackage and it’s functional but things like code signing on the Mac and auto updates for free would be lovely to have. Couple of questions:

1) Can I run jlink somewhere in the build process?

2) Can I use a private npm repo like Verdaccio, or are there plans for other (non npm?) backends in the future?

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#89

This is a passion project of mine to make it easier to deploy Java desktop apps. I'm very happy with the result, as IMO, the process is orders of magnitudes simpler than what we had before. Some features include: - Native installers for Mac, Windows, and Linux - Build native bundles for all platforms from any platform (e.g. You don't need Mac to make a Mac app. You don't need Windows to make a Windows app, etc..) - A…

> Auto updates. Your users automatically get the latest version on each launch How do you handle this? Are there hooks so that desktop apps can know to migrate state that's on disk?

The launcher gets the package's metadata from npm's registry on launch. This will tell it the latest version, and also the JVM requirements (e.g. version, javafx, jdk, etc..). It compares this with what it has installed. If it doesn't have the latest version, it will download it. If it already has a JVM that meets the requirements, it uses it. If not, it downloads one from Azul.

When it downloads a new version, it doesn't overwrite old versions. You can have two versions installed simultaneously. They are kept in $HOME/.jdeploy/packages/YOUR-PACKAGE/VERSION

It is also possible to peg your app to a particular version so that it doesn't auto update. Other variations are possible too, such as only autoupdating minor updates. E.g. Update to 2.1 or 2.2, but not to 3.0. For simplicity, I haven't exposes some of that yet.

There are no hooks. When your app runs, it is always running a particular version of the app. If your app needs to "transition" its resources when new versions are run, then that is up to you. No different than if the user downloaded and updated your app manually.

Re: JDeploy – Deploy desktop Java apps as native bundles on Mac, Linux, and Windows

#90

This is a passion project of mine to make it easier to deploy Java desktop apps. I'm very happy with the result, as IMO, the process is orders of magnitudes simpler than what we had before. Some features include: - Native installers for Mac, Windows, and Linux - Build native bundles for all platforms from any platform (e.g. You don't need Mac to make a Mac app. You don't need Windows to make a Windows app, etc..) - A…

No uninstaller on Windows? It doesn't show up neither in old control panel nor new remove programs list.

It's on my todo list. Will be added soon. https://github.com/shannah/jdeploy/issues/27
Post reply on HN