6 ms·

As suggested in the article, the usage of jpackage comes with a lot of drawbacks: - still a JRE is shipped (you MUST tailor it to the bare minimum with the fla

As suggested in the article, the usage of jpackage comes with a lot of drawbacks: - still a JRE is shipped (you MUST tailor it to the bare minimum with the flags) -> can be + ~30-40MB - OpenJFX/JavaFX relies on Qt (especially for the WebView) -> can grow up to + ~70MB - all the legal documents and docs are shipped together (you have to remove them with a post-process script) -> + ~5-10MB Using JVM for desktop apps is expensive in terms of space. Time can be reduced consistently thanks to the graal native compiler, but still a C++ project outperforms Java GUI applications by 500%

pjmlp 7y ago
OpenJFX/JavaFX uses WebKit for the WebView, Java never had any dependency to Qt. https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/CMakeLists.txt https://github.com/openjdk/jfx/blob/master/modules/javafx.we... I wonder where that 500% number came from, and yes C++ does blazing fast against Java in micro-benchmarks, except that on project delivery, developer salaries, time to market, additional costs for bug fixes (including memory corruption ones), available libraries, hardware costs for build performance also play a very big role.
- mister_hn 7y ago
  Indeed but Java Isn't that better compared to C++ when it comes to all those factors. There aren't memory corruption bugs, but the average number of Null pointer exceptions in fairly big projects can be daunting and relevant. Of course, Rust and Go here a big game changers in this way
  - pjmlp 7y ago
    Since we are speaking about desktop apps here, Rust and Go still have to offer something that is half as good as Swing, including graphical design tooling.
    - billfruit 7y ago
      I thought Rust desktop UI framework/libraries etc are still very much a work in progress.
      - pjmlp 7y ago
        Exactly, which is why "Rust and Go here a big game changers in this way" doesn't apply in this context.
        mister_hn 7y ago
        give them some time. And there's a Go API bridge for Qt
        pjmlp 7y ago
        So the proposition to have a better UI done in Go to beat Java is to use C++. Well, I can also call C++ from Java. In fact, once upon a time Qt had official Java bindings.
        billfruit 7y ago
        I agree with you, having a poorly documented qt binding which may break on any update is not the ideal way for a modern language to have GUI functionality. Java is good in the sense that it has JavaFX, a modern and rather full featured GUI framework available for it. Rust, Go, etc is very far from being recommended for production desktop apps with GUIs.
- mister_hn 7y ago
  Until Java 9, openjdk was requiring Qt 5 for OpenJFX because of the WebView, I clearly remember that. Still, shipping WebKit is pretty consuming
  - pjmlp 7y ago
    https://docs.oracle.com/javase/8/javafx/get-started-tutorial/jfx-overview.htm https://docs.oracle.com/javase/8/javafx/get-started-tutorial... > A web component that uses WebKitHTML technology to make it possible to embed web pages within a JavaFX application. Qt was indeed there, just like Gtk, EFL and every other plaform that is part of the WebKit source code vendoring inside the Java source code tree. http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc932af/modules/web/src/main/native http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc9... Which doesn't imply that the native code shipped with Java has any trace of Qt inside of it. https://www.oracle.com/java/technologies/javase-jdk8-downloads.html https://www.oracle.com/java/technologies/javase-jdk8-downloa...
- solarkraft 7y ago
  Consider my mind a little blown, however this seems to suggest that it's no longer the case: https://github.com/javafxports/openjdk-jfx/pull/48 https://github.com/javafxports/openjdk-jfx/pull/48
  - pjmlp 7y ago
    It was part of the WebKit vendoring and build process, as you can see in the source code, but it wasn't shipped with the JVM. http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc932af/modules/web/src/main/native/Source/WebKit http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc9...
thu2111 7y ago
Graal won't make apps run faster. The responsiveness of most Java desktop apps isn't CPU constrained, like on the web, slow reactions come from elsewhere. On the web it's mostly the heavy reliance on the server to do basic tasks meaning there's roundtripping. On desktop apps it's mostly like on mobile - if you hit disk or do other slow operations from the GUI thread then you can get "jank".
- pjmlp 7y ago
  Android here took a good approach actually, since developer education and lint checks apparently weren't enough, eventually Google changed the OS to kill an application that does such requests on the main thread.
  - solarkraft 7y ago
    I tend to think rigorous constraints are important to achieve software quality because when something stupid is possible someone's going to do it ("what's the problem? it works").
- karatestomp 7y ago
  On the web it’s mostly putting JavaScript between input and reaction/output, leading to input lag, and devs paying no attention to how much memory all those convenient JS data structures will eat and how slow it is to do stuff to them over and over. A few ms here, a few there, a ton of objects and lots of string concatenation, and boom, you’re using 1.5GB and your app feels slow as hell.
- ilikehurdles 7y ago
  Kind of surprising then that not a single major 3D, music, office, or photography production software is opting to use web technologies for the GUI on the desktop.
sdegutis 7y ago
I wonder if something like https://github.com/zserge/webview https://github.com/zserge/webview but using Lua for the backend side (to avoid the need to recompile it) would be lightweight in just the right ways while still being (almost) as good as Electron?

pjmlp 7y ago

OpenJFX/JavaFX uses WebKit for the WebView, Java never had any dependency to Qt. https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/CMakeLists.txt https://github.com/openjdk/jfx/blob/master/modules/javafx.we... I wonder where that 500% number came from, and yes C++ does blazing fast against Java in micro-benchmarks, except that on project delivery, developer salaries, time to market, additional costs for bug fixes (including memory corruption ones), available libraries, hardware costs for build performance also play a very big role.

mister_hn 7y ago
Indeed but Java Isn't that better compared to C++ when it comes to all those factors. There aren't memory corruption bugs, but the average number of Null pointer exceptions in fairly big projects can be daunting and relevant. Of course, Rust and Go here a big game changers in this way
- pjmlp 7y ago
  Since we are speaking about desktop apps here, Rust and Go still have to offer something that is half as good as Swing, including graphical design tooling.
  - billfruit 7y ago
    I thought Rust desktop UI framework/libraries etc are still very much a work in progress.
    - pjmlp 7y ago
      Exactly, which is why "Rust and Go here a big game changers in this way" doesn't apply in this context.
      - mister_hn 7y ago
        give them some time. And there's a Go API bridge for Qt
        pjmlp 7y ago
        So the proposition to have a better UI done in Go to beat Java is to use C++. Well, I can also call C++ from Java. In fact, once upon a time Qt had official Java bindings.
        billfruit 7y ago
        I agree with you, having a poorly documented qt binding which may break on any update is not the ideal way for a modern language to have GUI functionality. Java is good in the sense that it has JavaFX, a modern and rather full featured GUI framework available for it. Rust, Go, etc is very far from being recommended for production desktop apps with GUIs.
mister_hn 7y ago
Until Java 9, openjdk was requiring Qt 5 for OpenJFX because of the WebView, I clearly remember that. Still, shipping WebKit is pretty consuming
- pjmlp 7y ago
  https://docs.oracle.com/javase/8/javafx/get-started-tutorial/jfx-overview.htm https://docs.oracle.com/javase/8/javafx/get-started-tutorial... > A web component that uses WebKitHTML technology to make it possible to embed web pages within a JavaFX application. Qt was indeed there, just like Gtk, EFL and every other plaform that is part of the WebKit source code vendoring inside the Java source code tree. http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc932af/modules/web/src/main/native http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc9... Which doesn't imply that the native code shipped with Java has any trace of Qt inside of it. https://www.oracle.com/java/technologies/javase-jdk8-downloads.html https://www.oracle.com/java/technologies/javase-jdk8-downloa...
solarkraft 7y ago
Consider my mind a little blown, however this seems to suggest that it's no longer the case: https://github.com/javafxports/openjdk-jfx/pull/48 https://github.com/javafxports/openjdk-jfx/pull/48
- pjmlp 7y ago
  It was part of the WebKit vendoring and build process, as you can see in the source code, but it wasn't shipped with the JVM. http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc932af/modules/web/src/main/native/Source/WebKit http://hg.openjdk.java.net/openjfx/8/master/rt/file/f89b7dc9...

thu2111 7y ago

Graal won't make apps run faster. The responsiveness of most Java desktop apps isn't CPU constrained, like on the web, slow reactions come from elsewhere. On the web it's mostly the heavy reliance on the server to do basic tasks meaning there's roundtripping. On desktop apps it's mostly like on mobile - if you hit disk or do other slow operations from the GUI thread then you can get "jank".

pjmlp 7y ago
Android here took a good approach actually, since developer education and lint checks apparently weren't enough, eventually Google changed the OS to kill an application that does such requests on the main thread.
- solarkraft 7y ago
  I tend to think rigorous constraints are important to achieve software quality because when something stupid is possible someone's going to do it ("what's the problem? it works").
karatestomp 7y ago
On the web it’s mostly putting JavaScript between input and reaction/output, leading to input lag, and devs paying no attention to how much memory all those convenient JS data structures will eat and how slow it is to do stuff to them over and over. A few ms here, a few there, a ton of objects and lots of string concatenation, and boom, you’re using 1.5GB and your app feels slow as hell.
ilikehurdles 7y ago
Kind of surprising then that not a single major 3D, music, office, or photography production software is opting to use web technologies for the GUI on the desktop.

sdegutis 7y ago

I wonder if something like https://github.com/zserge/webview https://github.com/zserge/webview but using Lua for the backend side (to avoid the need to recompile it) would be lightweight in just the right ways while still being (almost) as good as Electron?