Live data from Hacker News

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

jdeploy.com

101–110 of 133 posts

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

#101
post #86
post #70

Earlier quoted context omitted.

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

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

What are you comparing against? VSCode with a ton of plugins to almost match IntelliJ? Because that's a lot slower than IntelliJ in my experience, not even close...

I am currently using IntelliJ heavily at work and I would agree it was too slow for a gigantic project we have... but there's literally no alternatives that work nearly as great (Eclipse, Emacs, VSCode, tried them all, they mostly can't even load a project like ours --- Eclipse can but it's a pain to index everything on re-builds)... but since I got a Mac M1 Pro, IntelliJ again feels light and snappy :D unfortunately, having the best hardware possible seems necessary now, as ever.

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

#102
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.

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

#103
post #101
post #86

Earlier quoted context omitted.

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

What are you comparing against? VSCode with a ton of plugins to almost match IntelliJ? Because that's a lot slower than IntelliJ in my experience, not even close... I am currently using IntelliJ heavily at work and I would agree it was too slow for a gigantic project we have... but there's literally no alternatives that work nearly as great (Eclipse, Emacs, VSCode, tried them all, they mostly can't even load a projec…

my expectation is that a 64GB 8 core Intel(R) Xeon(R) CPU E3-1230 v5 @ 3.40GHz with NVMe disk and nvidia graphics on the latest Debian should be much faster running PyCharm than it is in reality.

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

#106

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

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.)

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

#107

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

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.

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

#108
post #99

Earlier quoted context omitted.

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

The JVM updates very often now. This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM (as others pointed out, downloading two apps from the samples already shows the problem). With jlink , you don't need to download a whole JVM, it's usually a much smaller distribution. I have a LogFX application I distribute after passing it trhough jlink and it's around 30M…

> This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM

Not really. Currently it supports Java 8, 11, and 17. For each of those there is a JRE/JDK option, and a JavaFX option. Plus some of these are subsets. E.g. An app that doesn't need JavaFX can still use the JRE with JavaFX. And an app that doesn't need the full JDK can still use the JDK.

> as others pointed out, downloading two apps from the samples already shows the problem).

This was just an issue with the installer not needing JavaFX so downloading a non-javafx JRE first - but then the app needing JavaFX, so downloading one with JavaFX. This is a special case that will be resolved in an upcoming release by making the installer use a JRE that is compatible with the app to avoid the double download.

Anyways these are "fixed costs". Only incurred on first install. And, even then, maybe not if a compatible JVM is already present. All of your updates go through without the baggage of a JVM.

If you need more specific control over which JVM you're using than this (e.g. a specific build version or distribution), then jlink is a good tool for that. Life is about tradeoffs.

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

#109

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

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.

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

#110

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

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.)

Thanks. I saw the issue (presumably) you posted, and am setting up a VM to try to reproduce. Should have this fixed shortly.
Post reply on HN