8 ms·

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 sim

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..) - Auto updates. Your users automatically get the latest version on each launch - Small installer bundle size (3mb compressed) - No need to futz with Mac codesigning/notarization - Instant download page so your users can download your app as soon as its published. - Free, open source Please take it for a spin, and let me know what you think.

Fnoord 5y ago
Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place. Btw, font on website hurts my eyes, not easy to read. Its a font you'd use only by exception ie. italic usage (e.g. a quote). Not for a whole website.
- shannah78 5y ago
  > Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place. IMO this is moving back in the direction of the original WORA philosophy of Java. jDeploy is designed to be cross platform. No platform-specific build settings, to as much extent possible. After the death of Applets and WebStart, the new direction of bundle a JRE with every app - and rely on platform-specific 3rd-part tools to create the bundles never felt right to me.
  - drran 5y ago
    I definitely will not use jDeploy on Linux. Downloaded JVM, without disto-specific patches, is useless, because it will hang or segfault.
    - shannah78 5y ago
      I have received a few reports on Linux. I'm working on it. Literally this is the reason why jDeploy is helpful. I've spent 2 years working out many details. Every OS/Version/distribution has needed some special care. Up to now I've been working with a single Ubuntu 20 box for my linux testing. Today, in response to these reports, I'm setting up a number of Linux VMs to test other variations to get to the bottom of this. I should have these issues resolved shortly.
    - shannah78 5y ago
      I have reproduced this issue, and have posted and update that should fix it. Please try downloading either of the demos again and let me know if it still gives you issues.
usrusr 5y ago
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 jdeploy, is it adoptium? All of them? I've done dances like concatenating a zip to a pre-built nsis exe to get a windows installer from a Linux build server, jdeploy sounds like an interesting alternative!
- shannah78 5y ago
  > 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 for the curated JRE procurement? Here's the process. The launcher (written in C and Go) checks the npm registry to get the app's metadata (e.g. JVM requirements, versions, etc..). If the app needs to be updated, it will update it. If it needs to download a compatible JVM it downloads it. (But it reuses JVMs so if it already has one that meets requirements, it will use that). Currently it downloads from Azul. Used to use Adoptium but switched for JavaFX support reasons. Any of these pieces could be switched out pretty easily (npm -> self hosting, Zulu -> Adoptium, or self hosted, bundled VM, etc..).
  - gjvc 5y ago
    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).
victor106 5y ago
This looks very cool. What Java framework(Swing, FX etc) would you recommend for a desktop Java app?
- shannah78 5y ago
  > What Java framework(Swing, FX etc) would you recommend for a desktop Java app? Up to you. Swing is old faithful. JavaFX will result in something that is "cooler" and more modern. Both are supported. If you select "JavaFX" in JRE requirements, it will automatically use a VM with JavaFX to run your app so there's no penalty in app size for using JavaFX. If you are looking to target mobile, and also want to deploy to Desktop, you might want to check out Codename One. (Full disclosure: I work there). JavaFX and Swing aren't the only games in town either. jDeploy is part of my desire to make Java a more compelling choice for desktop app development. I still think it is too complex and overwhelming for new comers who just want to make a desktop app. I have some thoughts on how to simplify this, but I'll save that for another thread.
- brianguertin 5y ago
  There's an exciting desktop port of https://developer.android.com/jetpack/compose https://developer.android.com/jetpack/compose done by Jetbrains: https://github.com/JetBrains/compose-jb https://github.com/JetBrains/compose-jb
  - ta988 5y ago
    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.
    - danieldisu 5y ago
      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:)
WoodenChair 5y ago
Nice work and good explanatory website. I would like an easier process for deploying Java desktop apps, but the solution I use would need to also make it easier for me to deploy to the app stores (aka Mac App Store, Microsoft Store on Windows). Basically I would need a code signed app that I could submit to Apple.
- shannah78 5y ago
  jDeploy can be configured to produce an app like this, where everything is bundled together. It will even automate the codesign and notarize process. However, to do this requires a Mac, and you still need to jump through all Apple's crap for certificates etc... I haven't documented this process officially because I didn't want to confuse the primary message. For app store builds, jpackage is probably the way to go.
teaearlgraycold 5y ago
> 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?
- seinecle 5y ago
  I'd be curious about this one, too. This lib is great, maybe that it plays a role? -> update4J by mordechaim
- shannah78 5y ago
  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.
Folcon 5y ago
As someone who's had to recently setup jpackage for one of my side projects, which took forever and a day and I'm still not happy with the result. I'm very interested. Just glancing at the site, it really looks like this is something you put a bunch of effort into. I'll definitely check this out! So thanks.
helsinkiandrew 5y ago
A bugbear of mine having to use a couple of Java apps on my Mac is the non native window support. Do JBundle'd apps support native full screen size (not just expanding to fill the size of the screen, which allows other app windows to appear in front/behind), and native keyboard shortcut behaviour?
- aww_dang 5y ago
  SWT offers native UI support for Java apps, but the developer has to integrate it. https://www.eclipse.org/swt/ https://www.eclipse.org/swt/
- lf-non 5y ago
  This is more of a GUI concern, and I wouldn't expect a bundler like JDeploy to be able to do something about this. An appropriate GUI toolkit should be able to integrate with the native fullscreen. I briefly used the webview for java library [1] and it does the right thing because the browser handles it. JavaFX also supports [2] native fullscreen if appropriate integration is used. Not sure about Swing/AWT etc. [1] https://github.com/shannah/webviewjar https://github.com/shannah/webviewjar [2] https://docs.oracle.com/javase/8/javafx/api/javafx/stage/Stage.html#setFullScreen-boolean- https://docs.oracle.com/javase/8/javafx/api/javafx/stage/Sta...
alex_suzuki 5y ago
Interesting project. We build and maintain a significant cross-platform JavaFX app, and use a combination of JLink (to create a smaller executable with bundled JRE), install4j (for the native .app/.exe wrapper) and Packages (macOS)/InnoSetup (Windows) for the installer. The installer has a non-trivial amount of scripting under the hood so being able to customize that is really important, at least for us. I wonder if you won't run into trouble because of the Mac codesigning/notarization though. I think this poses a significant legal risk to you, as you are now distributing potentially malicious software signed with your certificate. Also I'm pretty certain Apple doesn't like this "code signing as a service" approach. But hats off, cool project!
- shannah78 5y ago
  > But hats off, cool project! Thanks!
- jdc22 5y ago
  Is the lack of notarization truly an issue? Aside from demonstrating that the creator has a paid subscription to the developer program, what does notarization accomplish that isn't already handled by XProtect (i.e. a YARA scan) and the Malware Removal Tool (MRT)? Are there any examples anywhere of malware that has slipped through the client-side XProtect pre-flight checks, but that the server-side notarization checks have caught? Most independent macOS security literature I've read implies that notarization and code-signing is more about retaining centralized control of the app distribution process, but does not actually contribute anything to the malware mitigation tools that have been built into macOS for a very long time.
  - alex_suzuki 5y ago
    Customers don’t want notarization prompts for their expensive, custom-built software packages… So even if the security benefit is negligible (I agree), if you want to play, you have to play by their rules.
    - deleted 5y ago
      [deleted]
ihateolives 5y ago
No uninstaller on Windows? It doesn't show up neither in old control panel nor new remove programs list.
- shannah78 5y ago
  It's on my todo list. Will be added soon. https://github.com/shannah/jdeploy/issues/27 https://github.com/shannah/jdeploy/issues/27
hoistbypetard 5y ago
The SwingSet demo didn't work at all for me on Linux. (I'm running fully patched Garuda KDE on x64, which is basically arch.)
- shannah78 5y ago
  Thanks. I saw the issue (presumably) you posted, and am setting up a VM to try to reproduce. Should have this fixed shortly.
- shannah78 5y ago
  This is fixed now. If you download the demo again it should work for you.
  - hoistbypetard 5y ago
    That fixed it here. It was a little odd that the new download had the same version number as the old, but it worked well.
    - shannah78 5y ago
      > It was a little odd that the new download had the same version number as the old The build number refers to your app version. The download page creates the bundle on the fly (but does cache) using the latest jDeploy release, so when I released the new version of jDeploy, the bundles in the download page are auto-updated. I thought of adding the jdeploy version number into the installer name, but it was getting pretty busy already, so I decided to just leave that off.
est 5y ago
> Small installer bundle size (3mb compressed) Is the 3M a launcher to download JRE & .jar files on-demand?
- shannah78 5y ago
  The launcher is about 3 megs compressed. The actual jar files and JVM are downloaded on demand in the $HOME/.jdeploy directory.

Fnoord 5y ago

Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place. Btw, font on website hurts my eyes, not easy to read. Its a font you'd use only by exception ie. italic usage (e.g. a quote). Not for a whole website.

shannah78 5y ago
> Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place. IMO this is moving back in the direction of the original WORA philosophy of Java. jDeploy is designed to be cross platform. No platform-specific build settings, to as much extent possible. After the death of Applets and WebStart, the new direction of bundle a JRE with every app - and rely on platform-specific 3rd-part tools to create the bundles never felt right to me.
- drran 5y ago
  I definitely will not use jDeploy on Linux. Downloaded JVM, without disto-specific patches, is useless, because it will hang or segfault.
  - shannah78 5y ago
    I have received a few reports on Linux. I'm working on it. Literally this is the reason why jDeploy is helpful. I've spent 2 years working out many details. Every OS/Version/distribution has needed some special care. Up to now I've been working with a single Ubuntu 20 box for my linux testing. Today, in response to these reports, I'm setting up a number of Linux VMs to test other variations to get to the bottom of this. I should have these issues resolved shortly.
  - shannah78 5y ago
    I have reproduced this issue, and have posted and update that should fix it. Please try downloading either of the demos again and let me know if it still gives you issues.

usrusr 5y ago

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 jdeploy, is it adoptium? All of them? I've done dances like concatenating a zip to a pre-built nsis exe to get a windows installer from a Linux build server, jdeploy sounds like an interesting alternative!

shannah78 5y ago
> 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 for the curated JRE procurement? Here's the process. The launcher (written in C and Go) checks the npm registry to get the app's metadata (e.g. JVM requirements, versions, etc..). If the app needs to be updated, it will update it. If it needs to download a compatible JVM it downloads it. (But it reuses JVMs so if it already has one that meets requirements, it will use that). Currently it downloads from Azul. Used to use Adoptium but switched for JavaFX support reasons. Any of these pieces could be switched out pretty easily (npm -> self hosting, Zulu -> Adoptium, or self hosted, bundled VM, etc..).
- gjvc 5y ago
  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).

victor106 5y ago

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

shannah78 5y ago
> What Java framework(Swing, FX etc) would you recommend for a desktop Java app? Up to you. Swing is old faithful. JavaFX will result in something that is "cooler" and more modern. Both are supported. If you select "JavaFX" in JRE requirements, it will automatically use a VM with JavaFX to run your app so there's no penalty in app size for using JavaFX. If you are looking to target mobile, and also want to deploy to Desktop, you might want to check out Codename One. (Full disclosure: I work there). JavaFX and Swing aren't the only games in town either. jDeploy is part of my desire to make Java a more compelling choice for desktop app development. I still think it is too complex and overwhelming for new comers who just want to make a desktop app. I have some thoughts on how to simplify this, but I'll save that for another thread.
brianguertin 5y ago
There's an exciting desktop port of https://developer.android.com/jetpack/compose https://developer.android.com/jetpack/compose done by Jetbrains: https://github.com/JetBrains/compose-jb https://github.com/JetBrains/compose-jb
- ta988 5y ago
  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.
  - danieldisu 5y ago
    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:)

WoodenChair 5y ago

Nice work and good explanatory website. I would like an easier process for deploying Java desktop apps, but the solution I use would need to also make it easier for me to deploy to the app stores (aka Mac App Store, Microsoft Store on Windows). Basically I would need a code signed app that I could submit to Apple.

shannah78 5y ago
jDeploy can be configured to produce an app like this, where everything is bundled together. It will even automate the codesign and notarize process. However, to do this requires a Mac, and you still need to jump through all Apple's crap for certificates etc... I haven't documented this process officially because I didn't want to confuse the primary message. For app store builds, jpackage is probably the way to go.

teaearlgraycold 5y ago

> 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?

seinecle 5y ago
I'd be curious about this one, too. This lib is great, maybe that it plays a role? -> update4J by mordechaim
shannah78 5y ago
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.

Folcon 5y ago

As someone who's had to recently setup jpackage for one of my side projects, which took forever and a day and I'm still not happy with the result. I'm very interested. Just glancing at the site, it really looks like this is something you put a bunch of effort into. I'll definitely check this out! So thanks.

helsinkiandrew 5y ago

A bugbear of mine having to use a couple of Java apps on my Mac is the non native window support. Do JBundle'd apps support native full screen size (not just expanding to fill the size of the screen, which allows other app windows to appear in front/behind), and native keyboard shortcut behaviour?

aww_dang 5y ago
SWT offers native UI support for Java apps, but the developer has to integrate it. https://www.eclipse.org/swt/ https://www.eclipse.org/swt/
lf-non 5y ago
This is more of a GUI concern, and I wouldn't expect a bundler like JDeploy to be able to do something about this. An appropriate GUI toolkit should be able to integrate with the native fullscreen. I briefly used the webview for java library [1] and it does the right thing because the browser handles it. JavaFX also supports [2] native fullscreen if appropriate integration is used. Not sure about Swing/AWT etc. [1] https://github.com/shannah/webviewjar https://github.com/shannah/webviewjar [2] https://docs.oracle.com/javase/8/javafx/api/javafx/stage/Stage.html#setFullScreen-boolean- https://docs.oracle.com/javase/8/javafx/api/javafx/stage/Sta...

alex_suzuki 5y ago

Interesting project. We build and maintain a significant cross-platform JavaFX app, and use a combination of JLink (to create a smaller executable with bundled JRE), install4j (for the native .app/.exe wrapper) and Packages (macOS)/InnoSetup (Windows) for the installer. The installer has a non-trivial amount of scripting under the hood so being able to customize that is really important, at least for us. I wonder if you won't run into trouble because of the Mac codesigning/notarization though. I think this poses a significant legal risk to you, as you are now distributing potentially malicious software signed with your certificate. Also I'm pretty certain Apple doesn't like this "code signing as a service" approach. But hats off, cool project!

shannah78 5y ago
> But hats off, cool project! Thanks!
jdc22 5y ago
Is the lack of notarization truly an issue? Aside from demonstrating that the creator has a paid subscription to the developer program, what does notarization accomplish that isn't already handled by XProtect (i.e. a YARA scan) and the Malware Removal Tool (MRT)? Are there any examples anywhere of malware that has slipped through the client-side XProtect pre-flight checks, but that the server-side notarization checks have caught? Most independent macOS security literature I've read implies that notarization and code-signing is more about retaining centralized control of the app distribution process, but does not actually contribute anything to the malware mitigation tools that have been built into macOS for a very long time.
- alex_suzuki 5y ago
  Customers don’t want notarization prompts for their expensive, custom-built software packages… So even if the security benefit is negligible (I agree), if you want to play, you have to play by their rules.
  - deleted 5y ago
    [deleted]

ihateolives 5y ago

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

shannah78 5y ago
It's on my todo list. Will be added soon. https://github.com/shannah/jdeploy/issues/27 https://github.com/shannah/jdeploy/issues/27

hoistbypetard 5y ago

The SwingSet demo didn't work at all for me on Linux. (I'm running fully patched Garuda KDE on x64, which is basically arch.)

shannah78 5y ago
Thanks. I saw the issue (presumably) you posted, and am setting up a VM to try to reproduce. Should have this fixed shortly.
shannah78 5y ago
This is fixed now. If you download the demo again it should work for you.
- hoistbypetard 5y ago
  That fixed it here. It was a little odd that the new download had the same version number as the old, but it worked well.
  - shannah78 5y ago
    > It was a little odd that the new download had the same version number as the old The build number refers to your app version. The download page creates the bundle on the fly (but does cache) using the latest jDeploy release, so when I released the new version of jDeploy, the bundles in the download page are auto-updated. I thought of adding the jdeploy version number into the installer name, but it was getting pretty busy already, so I decided to just leave that off.

est 5y ago

> Small installer bundle size (3mb compressed) Is the 3M a launcher to download JRE & .jar files on-demand?

shannah78 5y ago
The launcher is about 3 megs compressed. The actual jar files and JVM are downloaded on demand in the $HOME/.jdeploy directory.