11 ms·

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

277 points by shannah78 5y ago

Hakashiro 5y ago
"No codesigning" because JDeploy is codesigned. What will happen if malware is distributed like this? I doubt Apple would tolerate such blatant code signature abuse. Apple restrictions are not ideal but they're there for a reason.
shannah78 5y ago
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.
jeffreportmill1 5y ago
This is so nice - it solves the biggest problem of Java desktop deployment in a very elegant way! I have wasted so much time figuring out native app packaging and code signing (not to mention figuring it out on different platforms). I was able to get this to work in about 30 minutes. You are a hero - I hope this project really takes off! I dare say this is even better than Java Web Start (before it became hopelessly broken).
rmjill 5y ago
This looks like magic. Not sure how it generates native packages for multiple platforms without running on all of them.
- shannah78 5y ago
  The launcher, which is written in Go and C, is precompiled, so it can be reused in all apps. This means that, unlike jpackage, which requires you to build the Windows installer on Windows, the Mac installer on Mac, etc..., you can build for any platform from any platform. The idea is to fulfill the promise of WORA all the way to deployment. Everything is built and configured in a cross-platform way, and then is deployed as first-class native bundles on each platform.
  - tmilard 5y ago
    Thanks Shannah for the tool. I have always thought oracle was so uncool (and shooting in its own foot) not investing in better and easier deployment tool... I really will definitely try it out for my free-visit builder installer. If it works well like some have said, boy you saved my day ♥. Love
cosmotic 5y ago
This does indeed solve a significant burden. Relying on npm seems a bit awkward. I might suggest using native packages, especially on mac; something like a DMG or .package.
- shannah78 5y ago
  > 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. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish. > I might suggest using native packages, especially on mac; something like a DMG or .package. > 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. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish. > I might suggest using native packages, especially on mac; something like a DMG or .package The trouble with DMG and .pkg is that they need to be codesigned and notarized individually - which means you need a Mac and an Apple Developer account. Using jDeploy you don't need a Mac, and you don't need to worry about codesigning. This is because the installer is already signed and notarized. This probably the biggest pain point that I wanted to solve with jDeploy.
  - RandyRanderson 5y ago
    conda might be another option. Apparently it does anything (not just python packages). https://github.com/conda-forge/miniforge https://github.com/conda-forge/miniforge
  - cosmotic 5y ago
    I presume jdeploy is using its own code-signing to bootstrap the download and installation of other apps. Why not bootstrap a pkg?
geokon 5y ago
I don't really understand what this is offering. Maybe someone could explain.. Can't you already do this with jpackage or graalvm to create native bundles? At least with jpackage you already get an installer, versioning and upgradeability. I haven't tried graalvm'd native compiler but it should be possible as well.
- shannah78 5y ago
  > Can't you already do this with jpackage or graalvm to create native bundles? With jpackage or graalvm you need a Windows machine to build your windows installer because it relies on 3rd party Windows tools for the installer. Likewise on Mac and Linux. Even worse, on Mac you need to Codesign and Notarize the app, which is painful every time. > At least with jpackage you already get an installer, versioning and upgradeability. With jDeploy, it will check for updates when the app launches, and will download them automatically, so your users are always on the latest version.
- vips7L 5y ago
  I don't remember seeing auto update in jpackage.
  - seinecle 5y ago
    It must be handled differently, maybe with update4j
greatjack613 5y ago
This looks extremely scary to me, they say you can avoid having to noterize your apps with apple and microsoft because their installers are already approved. What happens when someone publishes some malware application using their wrapped and noterized installer? Apple and microsoft will then flag all other applications that used jdeploy as malware as well since they are all relying on the same noterized installer application. Super risky and definitely not a good approach from a security perspective.
- jeroenhd 5y ago
  It definitely bypasses signature checks on macOS and Windows. I don't know if that's actually a bad thing for security, though. Notarization and code signing has hardly posed a problem for malware on either platform so far.
  - ryan29 5y ago
    > Notarization and code signing has hardly posed a problem for malware on either platform so far. It's big business. They buy EV certs from what I've seen and no one in the industry cares about anything but the money.
- shannah78 5y ago
  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 from in your web browser. This works fine for many cases. A limitation is that apps built in this way can't be submitted to the app store. For that you would use jpackage or similar. But in most cases, this strategy is fine - and even better since it includes things like auto-updates.
  - unclebucknasty 5y ago
    >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?
Tommabeeng 5y ago
This is incredible. I’ve got two JavaFX apps to try this out with this week. Figuring out Mac codesigning for JavaFX apps was a pita.
- shannah78 5y ago
  Cool! Ping me when you get around to it. I'm still trying to put together some more samples for the homepage if you're willing to let me post them there.
ta988 5y ago
This is great, thanks a lot. I spent so many hours fiddling with jlink and modules and so on.
- shannah78 5y ago
  > I spent so many hours fiddling with jlink and modules and so on. Me too... Me too.
exabrial 5y ago
This actually serves an immediate need for us... we recently wrote a quite nice JavaFX desktop app to take care of some redundant data processing stuff and api pinging nonsense. Second coming of JNLP it looks like
- shannah78 5y ago
  Glad to hear! Please share them when you post them. Looking for more samples for the homepage. > Second coming of JNLP it looks like Yeah. JNLP always still felt a bit second class to me. The move to native bundles was, all in all, a good step, but the process was always too cumbersome.
  - exabrial 5y ago
    Some day... some day. I'd like a desktop toolkit that's designed around CDI / but more generally the Dependency Injection pattern. Imagine being able to break your application into chunks and @Observe events from user inputs.... ah, one can dream. But in case you get bored ;) I'll put that bug in you ear
- zmmmmm 5y ago
  > Second coming of JNLP it looks like Indeed! I never really understood how Sun screwed that part up so bad. It served a highly valuable need, but it seemed like they almost intentionally killed it by making the apps so awkward to deploy and manage from a security perspective it was non viable to use.
LoveGracePeace 5y ago
I appreciate the effort, Desktop Java is a viable platform. I however, am not interested in using it due to the NPM aspect. Get ready, this won't be popular but it feels like if my toe were on fire an I dowsed it with gasoline to put out the fire.
- shannah78 5y ago
  > I however, am not interested in using it due to the NPM aspect Some people (here and elsewhere) have expressed similar sentiments about NPM. What would be your preferred alternative? Self hosted? Github releases? Originally I built it to be self hosted, but NPM was just so darned easy to work with and made the process smoother, so I focused on that. NPM is really just a CDN in this context.
  - anaganisk 5y ago
    To be fair if your target segment is not privacy focussed HN crowd, think of an alternative option instead of npm release, dont try to replace it tho. In real world very less people want to go thru the hurdle of seeing things up. HN crowd has been wrong in some huge projects. Take the feedback and implement if it makes sense to your target segment.
  - BeefWellington 5y ago
    Speaking for myself, I could see this being useful to me if you targeted any kind of S3 target, along with something like Github Releases. Even just outputting the results to a filesystem location would be simple and appease a good chunk of the HN crowd I suspect. Similar to GP I wouldn't be trusting NPM with this kind of thing. For the convenience factor of it though, you should definitely leave that in place.
    - shannah78 5y ago
      > Similar to GP I wouldn't be trusting NPM with this kind of thing Have there been some events that cast doubt on the trustworthiness of NPM? vs, say Github?
msie 5y ago
This is great! Time to dust off my Swing books!
- shannah78 5y ago
  Here here! I sometimes pull out one of the old Swing books just for the enjoyment of nostalgia.
whartung 5y ago
I downloaded the Ensemble app for the Mac. I got a tar file, which, when expanded, gave me an app. I launched the app (who's name I do not recall), which proceeded to download a JRE...somewhere, and gave me (I think) another app. I launched that app, it, too, downloaded another JRE (so it said), and then launched the Ensemble app. The Ensemble app worked fine, but none of the source code from the samples was visible. I don't know if that's a packaging issue or not. Where did it install the JREs?
- shannah78 5y ago
  All files related to it are kept in $HOME/.jdeploy The observation that it downloaded 2 JREs (one for the installer and the other for the app) is a rough edge that will be fixed in an upcoming release. The reason is that the installer itself is an app that was bundled by jDeploy. It required a JRE, but didn't require JavaFX. When you, then launched the actual app, which was installed, it needed JavaFX, so couldn't use the JRE that was installed for the installer app, so it downloaded a JRE with JavaFX. I will be optimizing this so that the "installer app" will try to use a JRE that meets both the installer requirements and app requirements so it only needs to download one JRE. Hope that makes sense.
TeaVMFan 5y ago
This looks very impressive. "You must have a Mac to make a Mac binary" has always been an annoying shortcoming of jpackage, especially for smaller or independent developers. Congrats, and thanks. This is going to be very useful for many developers.
- shannah78 5y ago
  Thanks for the kind words. Looking forward to seeing how devs will use it.
  - brabel 5y ago
    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.
    - shannah78 5y ago
      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.
      - brabel 5y ago
        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.
seinecle 5y ago
Congrats on cracking the Mac notarization feature and other nightmare in the Mac release chain!
- lamontcg 5y ago
  Hope the author doesn't wind up back here in a few weeks after getting into a fight with Apple over that aspect.
  - alex_suzuki 5y ago
    I'm afraid this is a likely outcome.
    - bilbo0s 5y ago
      I think the feds might get to him first because the unfortunate reality is that the world is full of arseholes. One of those arseholes will surely use this system to distribute malware, and that malware will be signed with this guy's certificate. Which will lead the cops back to this guy. I have a feeling that apple will have to wait their turn on this one. It's only a matter of time before the inevitable happens.
    - anthony88 5y ago
      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.
savolai 5y ago
Beautiful. You might want to consider spelling codesigning as two separate words. The meaning / interpretation “co-designing” might be more prevalent for some users when spelled together. :)
stereo 5y ago
I use jpackage to build native bundles for JOSM, an editor for the OpenStreetMap project. As others have pointed out, one of the biggest shortcomings is that you have to use a Mac to build a Mac bundle, etc. https://github.com/JOSM/josm/blob/master/native/macosx/macos-jpackage.sh https://github.com/JOSM/josm/blob/master/native/macosx/macos... is my macos script, https://github.com/JOSM/josm/blob/master/native/windows/win-jpackage.sh https://github.com/JOSM/josm/blob/master/native/windows/win-... is the windows script, and for how it moves, see https://github.com/JOSM/josm/blob/master/.github/workflows/ant.yml https://github.com/JOSM/josm/blob/master/.github/workflows/a...
stereo 5y ago
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 in `~/Applications/jDeploy Apps` instead of the expected /Applications. The resulting application then doesn't have the expected The Unarchiver didn't like the JavaFX Ensemble 8 Installer-1.0.8_255X.tar.gz file, complaining about not being able to extract the Resources directory.
- shannah78 5y ago
  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)
  - stereo 5y ago
    12.2.1, latest everything.
suyash 5y ago
JavaFX and Swing is pretty solid technology for powerful making cross platform desktop apps.
thom 5y ago
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?
- shannah78 5y ago
  > 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.
  - thom 5y ago
    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?
    - shannah78 5y ago
      > Any plans for commercial features in the future? I'll have to find out what kinds of features are of interest to commercial clients. I'd like to find some way to support continued development. Commercial features are certainly a possibility.
comandillos 5y ago
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
- shannah78 5y ago
  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.
Zardoz84 5y ago
Very interesting! I would love to use, but my use case it's a bit weird : - I need to not use public npm. A private npm repository or a simple old plain http server would be fine. As we only need to give an URL to our clients to download it. - There is a way to control to what version auto updates ? I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated.
- shannah78 5y ago
  > I need to not use public npm. In a previous iteration everything was designed to be self-hosted, but decided to focus on npm support because it made things much simpler. I'll be re-exposing the self-hosting, and private npm options as demand dictates. > There is a way to control to what version auto updates? Internally it supports some rich update rules. It is possible to generate apps that are pegged to a specific version (e.g. 1.0.7), or that will only update build updates (e.g. 1.0.), or minor updates (e.g. 1.). By default they don't update to pre-releases (e.g. 1.0.1-alpha.1), but this is configurable by the user. I haven't documented this yet because I want to avoid confusion at the beginning as much as possible. There are dozens of variations that could be supported, but I'm trying to hit the 90% use case out of the box first... > I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated. You could just bake that into your client (detect the server version). Alternatively, just wait until the server is updated before you publish the client update. This could be triggered in CI as well.
Annatar 5y ago
The lengths people will go to in order to avoid learning such an incredibly rewarding technology like operating system packaging boggle the mind.
- shannah78 5y ago
  Hard to tell if this is sarcasm. However, I totally agree that learning about operating system packaging is a rewarding exercise. In developing jDeploy I had to learn a lot of details about OS packaging. Very interesting most of the time. Very frustrating at other times when all you want to do is build your app in a form that your users can easily install.
  - Annatar 5y ago
    It was not sarcasm, but disgust.
nevermindiguess 5y ago
Deleted

277 points by shannah78 5y ago

"No codesigning" because JDeploy is codesigned. What will happen if malware is distributed like this? I doubt Apple would tolerate such blatant code signature abuse. Apple restrictions are not ideal but they're there for a reason.

shannah78 5y ago

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.

jeffreportmill1 5y ago

This is so nice - it solves the biggest problem of Java desktop deployment in a very elegant way! I have wasted so much time figuring out native app packaging and code signing (not to mention figuring it out on different platforms). I was able to get this to work in about 30 minutes. You are a hero - I hope this project really takes off! I dare say this is even better than Java Web Start (before it became hopelessly broken).

rmjill 5y ago

This looks like magic. Not sure how it generates native packages for multiple platforms without running on all of them.

shannah78 5y ago
The launcher, which is written in Go and C, is precompiled, so it can be reused in all apps. This means that, unlike jpackage, which requires you to build the Windows installer on Windows, the Mac installer on Mac, etc..., you can build for any platform from any platform. The idea is to fulfill the promise of WORA all the way to deployment. Everything is built and configured in a cross-platform way, and then is deployed as first-class native bundles on each platform.
- tmilard 5y ago
  Thanks Shannah for the tool. I have always thought oracle was so uncool (and shooting in its own foot) not investing in better and easier deployment tool... I really will definitely try it out for my free-visit builder installer. If it works well like some have said, boy you saved my day ♥. Love

cosmotic 5y ago

This does indeed solve a significant burden. Relying on npm seems a bit awkward. I might suggest using native packages, especially on mac; something like a DMG or .package.

shannah78 5y ago
> 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. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish. > I might suggest using native packages, especially on mac; something like a DMG or .package. > 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. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish. > I might suggest using native packages, especially on mac; something like a DMG or .package The trouble with DMG and .pkg is that they need to be codesigned and notarized individually - which means you need a Mac and an Apple Developer account. Using jDeploy you don't need a Mac, and you don't need to worry about codesigning. This is because the installer is already signed and notarized. This probably the biggest pain point that I wanted to solve with jDeploy.
- RandyRanderson 5y ago
  conda might be another option. Apparently it does anything (not just python packages). https://github.com/conda-forge/miniforge https://github.com/conda-forge/miniforge
- cosmotic 5y ago
  I presume jdeploy is using its own code-signing to bootstrap the download and installation of other apps. Why not bootstrap a pkg?

geokon 5y ago

I don't really understand what this is offering. Maybe someone could explain.. Can't you already do this with jpackage or graalvm to create native bundles? At least with jpackage you already get an installer, versioning and upgradeability. I haven't tried graalvm'd native compiler but it should be possible as well.

shannah78 5y ago
> Can't you already do this with jpackage or graalvm to create native bundles? With jpackage or graalvm you need a Windows machine to build your windows installer because it relies on 3rd party Windows tools for the installer. Likewise on Mac and Linux. Even worse, on Mac you need to Codesign and Notarize the app, which is painful every time. > At least with jpackage you already get an installer, versioning and upgradeability. With jDeploy, it will check for updates when the app launches, and will download them automatically, so your users are always on the latest version.
vips7L 5y ago
I don't remember seeing auto update in jpackage.
- seinecle 5y ago
  It must be handled differently, maybe with update4j

greatjack613 5y ago

This looks extremely scary to me, they say you can avoid having to noterize your apps with apple and microsoft because their installers are already approved. What happens when someone publishes some malware application using their wrapped and noterized installer? Apple and microsoft will then flag all other applications that used jdeploy as malware as well since they are all relying on the same noterized installer application. Super risky and definitely not a good approach from a security perspective.

jeroenhd 5y ago
It definitely bypasses signature checks on macOS and Windows. I don't know if that's actually a bad thing for security, though. Notarization and code signing has hardly posed a problem for malware on either platform so far.
- ryan29 5y ago
  > Notarization and code signing has hardly posed a problem for malware on either platform so far. It's big business. They buy EV certs from what I've seen and no one in the industry cares about anything but the money.
shannah78 5y ago
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 from in your web browser. This works fine for many cases. A limitation is that apps built in this way can't be submitted to the app store. For that you would use jpackage or similar. But in most cases, this strategy is fine - and even better since it includes things like auto-updates.
- unclebucknasty 5y ago
  >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?

Tommabeeng 5y ago

This is incredible. I’ve got two JavaFX apps to try this out with this week. Figuring out Mac codesigning for JavaFX apps was a pita.

shannah78 5y ago
Cool! Ping me when you get around to it. I'm still trying to put together some more samples for the homepage if you're willing to let me post them there.

ta988 5y ago

This is great, thanks a lot. I spent so many hours fiddling with jlink and modules and so on.

shannah78 5y ago
> I spent so many hours fiddling with jlink and modules and so on. Me too... Me too.

exabrial 5y ago

This actually serves an immediate need for us... we recently wrote a quite nice JavaFX desktop app to take care of some redundant data processing stuff and api pinging nonsense. Second coming of JNLP it looks like

shannah78 5y ago
Glad to hear! Please share them when you post them. Looking for more samples for the homepage. > Second coming of JNLP it looks like Yeah. JNLP always still felt a bit second class to me. The move to native bundles was, all in all, a good step, but the process was always too cumbersome.
- exabrial 5y ago
  Some day... some day. I'd like a desktop toolkit that's designed around CDI / but more generally the Dependency Injection pattern. Imagine being able to break your application into chunks and @Observe events from user inputs.... ah, one can dream. But in case you get bored ;) I'll put that bug in you ear
zmmmmm 5y ago
> Second coming of JNLP it looks like Indeed! I never really understood how Sun screwed that part up so bad. It served a highly valuable need, but it seemed like they almost intentionally killed it by making the apps so awkward to deploy and manage from a security perspective it was non viable to use.

LoveGracePeace 5y ago

I appreciate the effort, Desktop Java is a viable platform. I however, am not interested in using it due to the NPM aspect. Get ready, this won't be popular but it feels like if my toe were on fire an I dowsed it with gasoline to put out the fire.

shannah78 5y ago
> I however, am not interested in using it due to the NPM aspect Some people (here and elsewhere) have expressed similar sentiments about NPM. What would be your preferred alternative? Self hosted? Github releases? Originally I built it to be self hosted, but NPM was just so darned easy to work with and made the process smoother, so I focused on that. NPM is really just a CDN in this context.
- anaganisk 5y ago
  To be fair if your target segment is not privacy focussed HN crowd, think of an alternative option instead of npm release, dont try to replace it tho. In real world very less people want to go thru the hurdle of seeing things up. HN crowd has been wrong in some huge projects. Take the feedback and implement if it makes sense to your target segment.
- BeefWellington 5y ago
  Speaking for myself, I could see this being useful to me if you targeted any kind of S3 target, along with something like Github Releases. Even just outputting the results to a filesystem location would be simple and appease a good chunk of the HN crowd I suspect. Similar to GP I wouldn't be trusting NPM with this kind of thing. For the convenience factor of it though, you should definitely leave that in place.
  - shannah78 5y ago
    > Similar to GP I wouldn't be trusting NPM with this kind of thing Have there been some events that cast doubt on the trustworthiness of NPM? vs, say Github?

msie 5y ago

This is great! Time to dust off my Swing books!

shannah78 5y ago
Here here! I sometimes pull out one of the old Swing books just for the enjoyment of nostalgia.

whartung 5y ago

I downloaded the Ensemble app for the Mac. I got a tar file, which, when expanded, gave me an app. I launched the app (who's name I do not recall), which proceeded to download a JRE...somewhere, and gave me (I think) another app. I launched that app, it, too, downloaded another JRE (so it said), and then launched the Ensemble app. The Ensemble app worked fine, but none of the source code from the samples was visible. I don't know if that's a packaging issue or not. Where did it install the JREs?

shannah78 5y ago
All files related to it are kept in $HOME/.jdeploy The observation that it downloaded 2 JREs (one for the installer and the other for the app) is a rough edge that will be fixed in an upcoming release. The reason is that the installer itself is an app that was bundled by jDeploy. It required a JRE, but didn't require JavaFX. When you, then launched the actual app, which was installed, it needed JavaFX, so couldn't use the JRE that was installed for the installer app, so it downloaded a JRE with JavaFX. I will be optimizing this so that the "installer app" will try to use a JRE that meets both the installer requirements and app requirements so it only needs to download one JRE. Hope that makes sense.

TeaVMFan 5y ago

This looks very impressive. "You must have a Mac to make a Mac binary" has always been an annoying shortcoming of jpackage, especially for smaller or independent developers. Congrats, and thanks. This is going to be very useful for many developers.

shannah78 5y ago
Thanks for the kind words. Looking forward to seeing how devs will use it.
- brabel 5y ago
  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.
  - shannah78 5y ago
    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.
    - brabel 5y ago
      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.

seinecle 5y ago

Congrats on cracking the Mac notarization feature and other nightmare in the Mac release chain!

lamontcg 5y ago
Hope the author doesn't wind up back here in a few weeks after getting into a fight with Apple over that aspect.
- alex_suzuki 5y ago
  I'm afraid this is a likely outcome.
  - bilbo0s 5y ago
    I think the feds might get to him first because the unfortunate reality is that the world is full of arseholes. One of those arseholes will surely use this system to distribute malware, and that malware will be signed with this guy's certificate. Which will lead the cops back to this guy. I have a feeling that apple will have to wait their turn on this one. It's only a matter of time before the inevitable happens.
  - anthony88 5y ago
    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.

savolai 5y ago

Beautiful. You might want to consider spelling codesigning as two separate words. The meaning / interpretation “co-designing” might be more prevalent for some users when spelled together. :)

stereo 5y ago

I use jpackage to build native bundles for JOSM, an editor for the OpenStreetMap project. As others have pointed out, one of the biggest shortcomings is that you have to use a Mac to build a Mac bundle, etc. https://github.com/JOSM/josm/blob/master/native/macosx/macos-jpackage.sh https://github.com/JOSM/josm/blob/master/native/macosx/macos... is my macos script, https://github.com/JOSM/josm/blob/master/native/windows/win-jpackage.sh https://github.com/JOSM/josm/blob/master/native/windows/win-... is the windows script, and for how it moves, see https://github.com/JOSM/josm/blob/master/.github/workflows/ant.yml https://github.com/JOSM/josm/blob/master/.github/workflows/a...

stereo 5y ago

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 in `~/Applications/jDeploy Apps` instead of the expected /Applications. The resulting application then doesn't have the expected The Unarchiver didn't like the JavaFX Ensemble 8 Installer-1.0.8_255X.tar.gz file, complaining about not being able to extract the Resources directory.

shannah78 5y ago
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)
- stereo 5y ago
  12.2.1, latest everything.

suyash 5y ago

JavaFX and Swing is pretty solid technology for powerful making cross platform desktop apps.

thom 5y ago

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?

shannah78 5y ago
> 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.
- thom 5y ago
  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?
  - shannah78 5y ago
    > Any plans for commercial features in the future? I'll have to find out what kinds of features are of interest to commercial clients. I'd like to find some way to support continued development. Commercial features are certainly a possibility.

comandillos 5y ago

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

shannah78 5y ago
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.

Zardoz84 5y ago

Very interesting! I would love to use, but my use case it's a bit weird : - I need to not use public npm. A private npm repository or a simple old plain http server would be fine. As we only need to give an URL to our clients to download it. - There is a way to control to what version auto updates ? I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated.

shannah78 5y ago
> I need to not use public npm. In a previous iteration everything was designed to be self-hosted, but decided to focus on npm support because it made things much simpler. I'll be re-exposing the self-hosting, and private npm options as demand dictates. > There is a way to control to what version auto updates? Internally it supports some rich update rules. It is possible to generate apps that are pegged to a specific version (e.g. 1.0.7), or that will only update build updates (e.g. 1.0.), or minor updates (e.g. 1.). By default they don't update to pre-releases (e.g. 1.0.1-alpha.1), but this is configurable by the user. I haven't documented this yet because I want to avoid confusion at the beginning as much as possible. There are dozens of variations that could be supported, but I'm trying to hit the 90% use case out of the box first... > I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated. You could just bake that into your client (detect the server version). Alternatively, just wait until the server is updated before you publish the client update. This could be triggered in CI as well.

Annatar 5y ago

The lengths people will go to in order to avoid learning such an incredibly rewarding technology like operating system packaging boggle the mind.

shannah78 5y ago
Hard to tell if this is sarcasm. However, I totally agree that learning about operating system packaging is a rewarding exercise. In developing jDeploy I had to learn a lot of details about OS packaging. Very interesting most of the time. Very frustrating at other times when all you want to do is build your app in a form that your users can easily install.
- Annatar 5y ago
  It was not sarcasm, but disgust.

nevermindiguess 5y ago

Deleted