Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jdeploy.com

Post reply on HN
Print view View original

91–100 of 133 posts

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

#91

Post by shannah78 »

stereo wrote: post #69

I'm getting an error about the SwingSet2 app being damaged when opening on macOS. Looking at it with Signet, I get: SwingSet2 Installer-1.0.5_255W/SwingSet2 Installer-1.0.5_255W.app error -67023 invalid resource directory (directory or signature have been modified) The JavaFX Ensemble 8 Installer-1.0.8_255X app opens, but the experience is very un-Mac-like: the app is really a custom installer, and it places an app i…

What version of Mac OS are you using? I've been testing on Mojave, Catalina, Big Sur, and Monterey. Can't seem to reproduce this (the "SwingSet2 damaged app)

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

#93

Post by shannah78 »

brabel wrote: post #76
shannah78 wrote: post #50

Earlier quoted context omitted.

Thanks for the kind words. Looking forward to seeing how devs will use it.

Why does it download a JVM separately instead of packaging the app with jpackage (which would result in a much smaller footprint)? EDIT: I mean jlink - jpackage would be an alternative to creating installers, but jlink just packages the app with parts of the JVM it requires, which seems could make this tool better by avoiding the need so maintain JREs (which are deprecated) on the user's machine.

By managing the JVMs separately, you get major savings on updates, or if you have multiple apps deployed this way since they can share a JVM. When you update your app, it only needs to download your app - not the whole JVM. You can even change the JVM requirements in your version updates, and it will adjust to the new requirements when it updates, possibly even downloading a new JVM if it doesn't have one that meets the requirements yet.

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

#94

Post by anthony88 »

alex_suzuki wrote: post #73
lamontcg wrote: post #61

Earlier quoted context omitted.

Hope the author doesn't wind up back here in a few weeks after getting into a fight with Apple over that aspect.

I'm afraid this is a likely outcome.

I've developed a lot of Java desktop apps and they use Apple Automator to start. This way I still get access to the disk without having to do the notarization.

If he has problems with Apple, it would be unfair compared to what is possible with Automator.

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

#95

Post by shannah78 »

cosmotic wrote: post #54
shannah78 wrote: post #7

Earlier quoted context omitted.

> Relying on npm seems a bit awkward. 1. npm solves a few problems here. By publishing to npm, the app is instantly available to be downloaded and installed by users. 2. Auto updating. The launcher will automatically check for updates on launch, and download them if any are found so that users are always working with your latest version. I may add support for other CDNs - and originally I just had it so you self host…

I presume jdeploy is using its own code-signing to bootstrap the download and installation of other apps. Why not bootstrap a pkg?

Yes the jDeploy installer is codesigned and notarized. The same installer is reused for every app. It figures out the specific app to be installed from a code in the installer name, so that, when run, the installer installs the correct app.

With a pkg I would need a different pkg for every app - which would need to be codesigned. Then we're back at the "need a mac to build mac app" issue. I wanted jDeploy fulfill WORA to whatever extent possible.

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

#96

Post by shannah78 »

comandillos wrote: post #92

In the case of macOS I would prefer to have an standalone app rather than an installer... I personally try to avoid using the classical installation process in macOS if there is a '.app' alternative

Yes, there is an app alternative. You can generate an .app directly with jdeploy. However, then you need to code-sign and notarize the app if you want users who download it to not see a "This app is damaged" message. The installer solve the code-sign problem because the installer is code-signed, and it reuses the same installer app for apps. When the app itself is installed in this way, it doesn't face the same quarantine restrictions as it would if it were downloaded from the internet.

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

#97

Post by shannah78 »

thom wrote: post #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?

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

No need. Just specify your JVM requirements and the launcher will automatically use (or download if necessary) a compatible VM. This allows JVMs to be shared between apps, and your app updates are much smaller since they don't include the VM bundled directly.

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

Right now it's pegged to the public npm repo, but I'll be exploring other options soon, including private repos, self hosting, GitHub releases.

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

#98

Post by thom »

shannah78 wrote: post #97
thom wrote: post #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?

> 1) Can I run jlink somewhere in the build process? No need. Just specify your JVM requirements and the launcher will automatically use (or download if necessary) a compatible VM. This allows JVMs to be shared between apps, and your app updates are much smaller since they don't include the VM bundled directly. > 2) Can I use a private npm repo like Verdaccio, or are there plans for other (non npm?) backends in the f…

Yeah, would just prefer not to download a whole JVM+JavaFX. It's also nice knowing _exactly_ what we're built against so we can thoroughly test.

Either way, really exciting stuff, we'll definitely have a play! Any plans for commercial features in the future?

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

#99

Post by brabel »

shannah78 wrote: post #93
brabel wrote: post #76

Earlier quoted context omitted.

Why does it download a JVM separately instead of packaging the app with jpackage (which would result in a much smaller footprint)? EDIT: I mean jlink - jpackage would be an alternative to creating installers, but jlink just packages the app with parts of the JVM it requires, which seems could make this tool better by avoiding the need so maintain JREs (which are deprecated) on the user's machine.

By managing the JVMs separately, you get major savings on updates, or if you have multiple apps deployed this way since they can share a JVM. When you update your app, it only needs to download your app - not the whole JVM. You can even change the JVM requirements in your version updates, and it will adjust to the new requirements when it updates, possibly even downloading a new JVM if it doesn't have one that meets…

The JVM updates very often now. This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM (as others pointed out, downloading two apps from the samples already shows the problem).

With jlink , you don't need to download a whole JVM, it's usually a much smaller distribution. I have a LogFX application I distribute after passing it trhough jlink and it's around 30MB.

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

#100

Post by brabel »

danieldisu wrote: post #84
ta988 wrote: post #23

Earlier quoted context omitted.

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 Win…

Arguably, Flutter has had even more work done... it's incredible how Flutter tools work so beautifully on all OS's.

I've played with Compose for Desktop and it's basically the Android framework, but running on desktop, as you might expect... but the tooling is currently not anywhere as good as Flutter IMO... and the customizations to make apps look like actual desktop apps (rather than mobile apps on Desktop which is just horrible) is currently impossible because there's just no docs on how to do it or any library that helps achieve that that I could find... Flutter, on the other hand, has multiple "themes" that work well on Desktop... I was amazed to watch a YT video where a Flutter guy showed how he implemented a Windows 3.1- like theme for Flutter and re-created a really old app for a customer that, for users, looks just like the old one (which was a strong requirement by the customer!).

Post reply on HN