[HN Gopher] Distribution of JVM Desktop Applications
___________________________________________________________________
Distribution of JVM Desktop Applications
Author : nfrankel
Score : 73 points
Date : 2021-02-14 19:45 UTC (3 hours ago)
(HTM) web link (blog.frankel.ch)
(TXT) w3m dump (blog.frankel.ch)
| bambam24 wrote:
| Tip of the decade , don't use anything related to Java.
| ertucetin wrote:
| There is a new problem with jpackage after JDK 14, when your app
| depends on native libs, you'll get UnsatisfiedLinkError. There is
| a ticket for that, but it seems that one core dev couldn't repro
| it and the ticket is closed now...
| https://bugs.openjdk.java.net/browse/JDK-8259661
| elygre wrote:
| The ticket is closed because the engineer found the bug report
| unconvincing, and needed more information.
|
| It is closed as "incomplete", which according to
| https://wiki.openjdk.java.net/display/HotSpot/Bug+Triage means
|
| > If the issue is incomplete, add a comment noting what is
| needed and close the bug as 'Resolved' - 'Incomplete'. This is
| our way of saying "need more information".
|
| This is the text from the actual bug report:
|
| > Looks like issue with provided demo app. [...] Please provide
| more complete example with command line used by jpackage,
| verbose output of jpackage and output of error message when
| resulting app is run from terminal.
| bullen wrote:
| I think the best way to do this is to just bundle a JRE in your
| application .zip?! You don't need an app to do that!
| pjmlp wrote:
| JRE has been replaced by jlink on Java 9.
|
| Each application is supposed to create their customised
| runtime.
| pron wrote:
| > Java Web Start. This is the canonical way for desktop
| applications.
|
| Not anymore. Java Web Start was removed because the very concept
| of a JRE, a system-wide runtime downloaded directly from Oracle
| and managed by the user or their IT department, no longer exists
| (despite some OpenJDK distributions offering something they call
| a JRE -- perhaps to maintain a sense of familiarity -- no one
| actually provides a JRE anymore, although I guess OpenWebStart is
| attempting to resurrect it). Like any other application, Java
| applications now only have two parties: the user and the
| application's vendor. It is the responsibility of the vendor to
| deliver the application along with any dependency, including a
| Java runtime. The vendor may choose to supply their own automatic
| update mechanism, for the application _and_ the runtime, but
| users need not interact directly with the Java runtime anymore.
|
| Web Start, like Applets, was entirely predicated on the notion of
| the JRE. With the latter gone, the former is meaningless.
|
| Why was the JRE discontinued?
|
| 1. The software ecosystem now discourages system-wide third-party
| runtimes. On the desktop, the app store model rules; on the
| server, containers are popular -- both are much more friendly to
| an embedded runtime.
|
| 2. An embedded runtime with jlink gives the user a better
| experience by giving the software vendor full responsibility over
| their software and not requiring the user to deal with runtime
| components they don't, and need not, understand (although,
| admittedly, popular Java build tools currently lag in their
| support for jlink). In other words, the new way is better, but it
| does require getting used to.
|
| > While it can in theory work with any application, it shines
| with modularized applications.
|
| Not just in theory. jlink is _the_ recommended practice for
| deploying any Java application, desktop or server, modular or
| not. While a modular application can help automate more steps of
| the packaging process (like not requiring running jdeps to find
| dependencies and automatically generating launcher scripts),
| jlink is not especially tied to modular applications. It is how
| _all_ Java applications should be distributed (jpackage
| internally uses jlink).
|
| (I work at Oracle on OpenJDK)
| chungy wrote:
| > Not anymore. Java Web Start was removed because the very
| concept of a JRE, a system-wide runtime downloaded directly
| from Oracle and managed by the user or their IT department, no
| longer exists (despite some OpenJDK distributions offering
| something they call a JRE -- perhaps to maintain a sense of
| familiarity -- no one actually provides a JRE anymore
|
| Then what does the "java" command do exactly, if not run Java
| applications in some kind of runtime environment?
|
| > It is the responsibility of the vendor to deliver the
| application along with any dependency, including a Java
| runtime.
|
| Honestly, this appears to destroy a fundamental promise that
| Java made when it was first released: Write once, run anywhere.
| And not just in the present, but for future systems as well.
| Are we now expected to have vendors provide 30 different
| downloads tailored for every operating system and architecture
| combination possible? And if that application needs to be run
| in 10, 20 years when the packages that were made can no longer
| run directly?
|
| It seems like a fairly dismal state of affairs, to me.
|
| > 1. The software ecosystem now discourages system-wide third-
| party runtimes. On the desktop, the app store model rules
|
| Does "desktop" only include Mac OS? Neither on Linux nor
| Windows does the "app store model" rule. They exist, but are
| more like an obscure "you can also do it this way" method
| rather than the norm.
|
| > on the server, containers are popular -- both are much more
| friendly to an embedded runtime.
|
| Containers are indeed popular, and maybe an embedded-JRE makes
| sense. I personally stick with installing whatever JRE package
| comes with Debian, myself; run them the traditional way.
|
| It certainly clears up a lot of uncertainty about the security
| of whatever Java runtime is being used, when a distribution
| (eg, Debian, Fedora, RHEL, etc) with a reputable security team
| takes care of that issue for me. The Java runtime gets updated,
| my servers restart, instant security buff. Trusting this to
| software vendors is just insane.
|
| > although, admittedly, popular Java build tools currently lag
| in their support for jlink
|
| This seems to show that developers haven't bitten the Oracle
| dream of vendored JREs. The "old" way of launching Java
| applications, both desktop and server, works perfectly fine to
| the present day, and few seem to be willing to alter that.
| jcelerier wrote:
| > Then what does the "java" command do exactly, if not run
| Java applications in some kind of runtime environment?
|
| if you're using a normal desktop OS there's no system-wide
| "java" command (anymore (thankfully))
|
| It's just a new iteration of the eternal software cycle :
|
| 10: "apps are shipped together with all their libraries /
| dependencies ! space is wasted / all apps must be upgraded
| when there is a security issue instead of one single dll !
| let's share the runtime/DLLs/whatever which will solve all
| our issues !"
|
| 20: "oh no ! all apps are now dependent on a single
| runtime/DLL which {does not updates as fast as upstream |
| must be installed manually by the user who is clueless and
| will use the competition's software which JustWorks(tm)
| instead | causes DLL hell | must be patched to work with my
| software in a way that would break other software using the
| same runtime }, let's switch to static linking / bundling
| everything !"
|
| GOTO 10
| chungy wrote:
| > if you're using a normal desktop OS there's no system-
| wide "java" command (anymore (thankfully))
|
| Just about every Linux desktop, especially with LibreOffice
| installed, will have a system-wide java command. It is
| entirely normal and expected.
| kenniskrag wrote:
| Not really more space if you do not use all symbols. More
| info here: https://drewdevault.com/dynlib
| Macha wrote:
| > Does "desktop" only include Mac OS? Neither on Linux nor
| Windows does the "app store model" rule. They exist, but are
| more like an obscure "you can also do it this way" method
| rather than the norm.
|
| Even on mac OS, how much is it the norm? I think my only app
| store app on my work MBP is Slack.
| simonh wrote:
| > Honestly, this appears to destroy a fundamental promise
| that Java made when it was first released: Write once, run
| anywhere.
|
| Correct. And I'm fine with that, it was a terrible idea right
| from the start for most use cases IMHO. If I never need to
| maintain a system wide Java again to run user applications I
| will be very happy.
|
| The purpose of system runtimes (for Java, Python, whatever)
| is for running system components IMHO. User installed
| application dependencies beyond actual OS components are a
| user/vendor issue and I think the right way to handle that is
| on a per application basis.
| btown wrote:
| Other than size savings for the download and storage of
| potentially redundant things-formerly-known-as-the-JRE, were
| there performance benefits to having a shared JRE?
|
| Theoretically, a slow but Java-optimized system could cache
| (components of) the JRE in memory and make those pages
| available to novel JRE-based executables, much like a binary
| shared library [0]. Was this ever done in practice? I imagine
| it would have sped up Java Web Start startup times considerably
| - and mobile platforms as well, perhaps?
|
| [0]: see for instance
| https://unix.stackexchange.com/questions/458112/how-to-ensur...
| usrusr wrote:
| On the desktop a clear no, on the server, back when you still
| had "apps per server" instead of "servers per app", who knows
| what might have been going on between the classloader
| hierarchies of your favorite EE platform and it's JVM.
| fredgrott wrote:
| ahem I have a jre on ms windows recent Amazon distribution
|
| as the jdk doe sin fact embed a jre
|
| JRE is not discontinued still will be separate download for
| just a jre
| c-smile wrote:
| 1. Create minimal JVM and runtime with GUI primitives and compile
| it into .EXE
|
| 2. Create packager that concats class files (in JAR) of your
| application with that EXE.
|
| 3. Sign the exe. That's your monolithic application without
| external dependencies.
|
| Done. You can distribute your Java applications without any need
| for JRE, WebStart or anything like that.
|
| Did that once as J-SMILE
| (https://terrainformatica.com/org/j-smile/) project.
|
| That minimal JVM was of size 300 kb so nothing if to compare with
| the rest of .class files of your app. So Java executables can be
| in principle smaller than comparable Go's executables.
| TeaVMFan wrote:
| The easiest way to distribute JVM applications on the desktop is
| the via the browser. TeaVM and Flavour make it easy to build rich
| browser apps in no time. You won't even miss Swing or JavaFX!
|
| Intro article: https://blogs.oracle.com/javamagazine/java-in-the-
| browser-wi...
|
| Migrating from Swing to TeaVM:
| https://frequal.com/TeaVM/migration/MigratingFromSwingToTeaV...
|
| A recent success story migrating from applets to TeaVM:
| https://news.ycombinator.com/item?id=26135892
| walkingolof wrote:
| Scala.JS is an alternative if you write Scala, a compile target
| for the browser (or Node of course) that also can use most
| Typescript libraries via the Scalablytyped plugin
| MaxBarraclough wrote:
| No mention of Graal. Does Graal Native Image work well with
| JavaFX? Seems appropriate to use ahead-of-time compilation for
| desktop applications.
| spijdar wrote:
| What's the story with JavaFX nowadays? I'm not a Java dev, but
| from a user perspective it's a bit of a PITA since OpenJDK
| doesn't (?) package JavaFX with it (and neither does the latest
| oracle JRE/JDK?). It seems to be open source but the main
| program I'm thinking of, an old-school raytracer for minecraft
| Chunky [0] requires it be packaged with the JDK, hence the
| requirement for _Java 8_.
|
| Is this just laziness on the part of those devs to not package
| it up or is there something else going on?
|
| [0] https://github.com/chunky-dev/chunky
| vbezhenar wrote:
| AFAIK you need to include JavaFX DLLs with your application
| and configure appropriate java.library.path. It's not
| laziness, JavaFX is not part of Java anymore, so you need to
| deploy it like any other native component.
| MaxBarraclough wrote:
| JavaFX is no longer part of the core OpenJDK distribution,
| but it's not dead and gone, it's just maintained separately.
|
| There's no need to stay on Java 8 to use JavaFX, although I'm
| not qualified to speak on whether it would be a lot of effort
| to upgrade a JavaFX application to a newer Java.
| fiddlerwoaroof wrote:
| One issue is that I think Oracle forced package renames
| and, afaik, there's no compatibility layer available for
| packages that expected the old Class Names. To my mind,
| this sort of defeats the purpose of the JVM's universally
| unique symbol names.
| MaxBarraclough wrote:
| I don't think so. They were named _javafx..._ both before
| and after, no?
|
| Doesn't sound like a real problem though. Renaming things
| is the easiest kind of change to accommodate.
| fiddlerwoaroof wrote:
| I think I'm confusing it with the Java EE changes.
| However, renaming is only easy to accommodate if you have
| source access. The JVM's model is portable binaries, so
| forcing renames breaks some of that model.
| MaxBarraclough wrote:
| True, it would break binary compatibility.
| pvorb wrote:
| Yes, this indeed looks like laziness of the developers to me.
| When the app was developed, JavaFX came pre-packaged with the
| JDK/JRE, so they still rely on it. Today, it should perhaps
| just be a regular dependency of your app and be part of your
| app.
|
| If I were to build a Java desktop application today, I would
| even bundle the entire JRE, since you cannot assume that it
| is installed on most desktops anymore.
| divs1210 wrote:
| It does. JavaFX + Graal Native is even used to make native
| mobiles AFAIK.
| jorl17 wrote:
| Many years ago, I wrote jar2app:
| https://github.com/Jorl17/jar2app
|
| At the time, I had a Minecraft jar on my hands, and I was tired
| of it not showing up in Spotlight's results because it was "just"
| a Jar. So I cobbled together this lazy script to get around that.
| I guess I got carried away writing the documentation when I
| published it, but it was never meant to be used "in production".
|
| People often stumble upon the project and pose questions (same
| goes with some of my other projects like the barely-standing
| https://www.open-elevation.com/ ), but I just don't have the
| energy and time to fix things, answer issues and all tat jazz
|
| I feel _really_ bad for not helping people out, clearing their
| doubts, fixing their issues, and improving my "creations" that
| were thrown out into the world. It's just that from my
| perspective, these things I built are extremely simple, mostly
| weekend-projects, which were for my own use, and I just happened
| to put them out there to help out whoever needs them. I accept
| donations on https://www.open-elevation.com/ to try to at least
| break-even on the cost of the hardware (I don't, not even close,
| but that's okay), but really I don't have time and energy to help
| out...
|
| All this to say that I'm sure if I had put in just a tiny bit of
| effort throughout the years, even if just by looking at issues
| and pull requests created by others, I'm sure jar2app could be on
| this list (and _especially_ because of the work that others could
| have put into it, if I just provided them with feedback once in a
| while).
|
| So, if anyone's out there, I'm sorry! I really just don't have
| the time, energy and in some cases the money...
| foobiekr wrote:
| The very few Java desktop applications I've been inflicted with
| have been terrible. Memory hogs, terrible UI, etc.
|
| Maybe the time has simply passed?
| utku_karatas2 wrote:
| Time has passed and more importantly Electron based apps
| lowered the expectations of desktop users.
|
| I use dbeaver (https://dbeaver.io/) as my go-to database tool
| and it's absolutely fine. Not as snappy as native apps for
| sure, but between Spotify, Slack and VSCode I can't really
| complain. I used to... but not anymore.
| rstupek wrote:
| As opposed to electron apps which are thin memory users and
| paragons of UI
| pvorb wrote:
| So much this. I understand that it's easiest to reuse your
| react skills to build your desktop application, but why does
| it have to consume so much memory? Is this something that's
| wrong with electron or rather the UI frameworks that run on
| it?
| uncledave wrote:
| Problem is it's turtles all the way down. A lot of turtles.
| Each turtle is hungry.
| beders wrote:
| Intellij is written in Swing. Yes on memory hog, no on terrible
| UI. It works quite well across platforms (I'm using the Windows
| and Mac version)
| Kwpolska wrote:
| IntelliJ uses a ton of custom widgets and styles, and
| nowadays even a custom JVM build to look the way it does. And
| on Linux, fonts in IntelliJ are hit-and-miss in my
| experience.
| beders wrote:
| I sure hope it uses tons of custom swing widgets.
|
| That's something the Java team never got right: the cross-
| platform look&feels looked just awful.
___________________________________________________________________
(page generated 2021-02-14 23:00 UTC)