
Using Java 9 Modularization to Ship Zero-Dependency Native Apps - StevePerkins
https://steveperkins.com/using-java-9-modularization-to-ship-zero-dependency-native-apps#.Wes5Y7ucK4g.hackernews
======
phreack
While Electron's popularity was a boon to the desktop app scene, I keep on
dreaming that JavaFX applications made with Kotlin, jlink, Gluon's scene
builder (or maybe even something better) will gain enough popularity to
attract a healthy open source community for cross platform desktop apps.

It feels like the tools are almost where they need to be and finally coming
together!

~~~
adamhepner
OK, so question time: I haven't done any Java (let alone Kotlin) coding now
for what seems like ages, but will need to implement a relatively simple, yet
cross-platform client for my upcoming application. It will probably sound
extremely silly, but were I to write a GUI that speaks to a REST API, where
should I start doing my research?

~~~
phreack
If you have more recent experience on C++, Python or Javascript then you
should be looking into Qt, PyQt, Electron (respectively) or other alternatives
first, but if you're willing to try the Java environment you could look into
the following components to get you started:

-Kotlin to speed up development

-Gradle as a dependency manager

-Retrofit + OkHTTP to create a type safe backend API definition

-JavaFX for the GUI components

-Gluon's scene builder if you like creating your FX views in xml, with a visual editor

-RX as a powerful library for async tasks

-Gson or Jackson as a JSON parsing library

-IntelliJ if you like coding with IDEs, for its massive refactoring capabilities

It's a lot to take in if you're unfamiliar, but together they all come to form
really solid desktop applications.

------
capelio
_Even so, Java is now at a place where you can ship self-contained, zero-
dependency applications that are comparable in size to other compiled
languages (and superior to web-hybrid options like Electron).

For cross-platform desktop GUI apps, I would argue that JavaFX combined with
Java 9 modularization is hands-down the best choice available today._

Electron is succeeding in the desktop GUI space because it tears down the
barriers to desktop app development. While the author's article is excellent,
when it comes to Electron, he (like most engineers) is still missing the
point: the choice between Electron and its alternatives doesn't pivot on file
size.

~~~
ssijak
Well, will see how Electron will pan out in the end. While I dislike default
Java Swing GUI (it can be made easily to look native but many devs previously
did not do it), JavaFX can be made to look like anything with almost weblike
feel to development and animations. Now, more than the looks I dislike the
slowness and utterly unacceptable memory Electron apps consume. I ditched
Electron and VSCode (it is a little better than Atom) because I don`t want to
have my text editor eat 500mb ram to open 1 medium file and crash on large
ones. Same for Slack and other Electron apps. And it is not even funny to see
dev console when some Atom plugin or whatever crash. I`m interested how many
devs also ditched this two editors ONLY because of Electron bloat.

~~~
pjmlp
Electron pop culture made me buy Sublime Text.

~~~
ssijak
For me it finally pushed me enough to switch to Vim for web dev work. But I do
have Sublime for just in case.

------
tootie
While everyone is excited about how this helps desktop app development, this
is also going to simplify server deploys. If you've got a full java stack, you
won't need to do anything to provision a server.

~~~
tuananh
i think this is a better selling point.

------
firdak
So, after "optimizations [...] to further reduce the resulting bundle size", a
Java command-line "Hello World" is still 21.7 MB. I've found a Node.js version
(using node-packer [1]) to be about the same size.

However, as mentioned in the article, "Hello World" in Go is an order of
magnitude smaller. The article may be right that Java is "the best choice
available" for cross-platform GUI apps, but for cross-platform command-line
tools, I think Go is currently the best option. IMO Go provides the best
tradeoff between ease of development, ease of distribution and runtime
performance.

[1] [https://github.com/pmq20/node-packer](https://github.com/pmq20/node-
packer)

~~~
nerdponx
2.17 MB is still enormous for a "hello world" binary.

~~~
c_shu
No. 2.17 MB is NOT enormous. Usually there is no runtime library. In contrast,
C or C++ runtime libraries can easily exceed that size. For example,
vc_redist.x64.exe is 13.9 MB.

~~~
joosters
(Note: The size in the article is 21.7 MB, and not 2.17 MB!)

I just tried building a statically linked 'hello world' c++ program, and co-
incidentally, the binary also happened to be 2.1 MB!

    
    
       #include <iostream>
       
       int main( int, const char *[] )
       {
          std::cout << "Hello World!" << std::endl;
          return 0;
       }
    
    

'g++ -static -o hello hello.cpp' produces a binary of 2191112 bytes (Linux
x64). Stripping it of debug symbols leaves a 1.7 MB file.

~~~
taspeotis
[http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...](http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html)

------
generichuman
I want to use JavaFX to develop cross-platform apps but I feel JVM uses too
much memory even for little things.

It's been a while since I've used Java to program, has the memory situation
changed? or are there any other solutions for lowering the JVM memory usage?

~~~
slackingoff2017
Java will use as much memory as you give it. Higher heap size is better for
performance up to around 32GB. For most Java apps you can limit heap to 256M
or less with little consequence.

AFAIK Java uses less ram than Python and JavaScript, only common languages
that beat it are Golang and C/C++

~~~
nextos
And memory used will be hopefully quite lower with value types, coming
sometime in the future:

[http://www.jesperdj.com/2015/10/04/project-valhalla-value-
ty...](http://www.jesperdj.com/2015/10/04/project-valhalla-value-types/)

------
0xFFC
Great article. Pair this with AOT. Then you have unbeatable combination.
Productivity of java with availability of Native features. Count me in!

------
jrs95
This looks pretty awesome. I haven't used JavaFX before, but if it's easy
enough to deliver high quality UX with it, I'll be using this for any side
project desktop apps I end up working on.

------
bmn__
TFA reads like GCJ does not exist, a classic lie by omission. Don't become a
victim of misinformation!

Compiling to small, native binaries (i.e. JRE not needed) is possible since at
least 10 years ago. Let's examine this application as an example:
[http://sancho-gui.sf.net](http://sancho-gui.sf.net)

    
    
        /tmp/sancho-0.9.4-59-linux-gtk$ ls -hs ./sancho
        13M ./sancho
    
        /tmp/sancho-0.9.4-59-linux-gtk$ du -hs ./lib
        740K ./lib
    
        /tmp/sancho-0.9.4-59-linux-gtk$ ldd ./sancho
        linux-gate.so.1 (0xf7f71000)
        libm.so.6 => /lib/libm.so.6 (0xf7e30000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf7e11000)
        librt.so.1 => /lib/librt.so.1 (0xf7e07000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7e02000)
        libc.so.6 => /lib/libc.so.6 (0xf7c29000)
        /lib/ld-linux.so.2 (0xf7f73000)

~~~
kryptiskt
GCJ is dead, there is no development and it has been removed from GCC.

------
zengid
I'm unfamiliar with the state of the art, but could this make it possible to
target iOS with a bundled JVM?

~~~
filereaper
iOS tends to favour direct native code, hence the use of Objective C and Swift
for iOS development.

Given the already large ecosystem built on these lanuages, its unlikely
they'll pivot to a JVM based system.

~~~
pjmlp
There are AOT native Java compilers for iOS, the majority just tends to ignore
them.

------
ksec
15 years since I last looked at Java for Desktop Apps and shipping as binary.
I remember there were also GCJ as the commercial JET alternative.

Graal and Truffle are progressing along. I wonder what happen to SubstrateVM,
which allows AOT of Java. I assume with SVM the binary size can be further
reduced and much faster startup time.

------
mmargerum
Boy if I could pair this with Clojure I’d seriously consider building desktop
apps again.

------
i386
Oracle have broken and delayed releases of Java so some people can get slimmer
binaries? Hardly seems like a good trade off when storage is the cheapest it’s
ever been.

~~~
blinkingled
It's not about storage. Most desktops don't have a JRE installed and
downloading the full non-modular JRE and installing it before being able to
run the program is a hassle compared to providing a stripped down, self
sufficient, linked version of the app that's one third in size.

~~~
i386
Who cares about desktop apps? Most Java development is done on the server
where the size of your runtime isn't a constraint. Breaking reflection,
delaying language features, releases, etc is a very poor tradeoff for the
module system that has been delivered.

~~~
blinkingled
Well, now you can care about Java desktop apps - that's kind of the point of
all this :)

And server apps don't really switch that fast to newest Java release. Only now
we're seeing JDK7 based things for example.

------
tpolzer
Does it have cross platform Hi-DPI support? No.

~~~
ZenoArrow
Are you joking? I can't tell.

Just in case you aren't, what do you think is required for a platform to
support Hi-DPI displays?

~~~
Pyxl101
I'm not the OP, but I assume hi-DPI support means that applications scale up
their GUI sizes appropriately based on the DPI.

When I use a hi-DPI display (like 4K displays), a lot of old software renders
text and widgets too small to see, because they were programmed to display
things as so-many pixels high, without concern for DPI. It's frequently a
problem with old video games, though it affects regular applications too.

~~~
Sophistifunk
It's more than that, simply pixel-doubling the UI is also terrible. Real hi-
DPI support (to me) is actually rendering at hi-dpi.

~~~
ZenoArrow
What difference does it make if the standard resolution is Hi-DPI or not? Can
you visually tell the difference between pixel doubling and other methods of
designing for Hi-DPI?

------
camus2
> A “Hello World” CLI written in Go compiles to around 2 MB.

Nitpick but hello-world in Go :

    
    
        package main
       
        func main(){
            print("Hello World")
        }
    
    

is < 1MB on most computers (900KB on windows). No need to import the "fmt"
package.

~~~
pjmlp
Except that isn't actually portable Go code, because you are using an
unsupported function that can be removed at any time.

"The print built-in function formats its arguments in an implementation-
specific way and writes the result to standard error. Print is useful for
bootstrapping and debugging; it is not guaranteed to stay in the language."

[https://golang.org/pkg/builtin/](https://golang.org/pkg/builtin/)

------
0xbear
“Zero dependency” after you install a 80MB JRE. You keep using this word. I
don’t think it means what you think it does. Statically linked C is zero
dependency. Go is zero dependency. Copy a binary to the target system and it
runs. There’s nothing else to install.

~~~
kbenson
It gets a little fuzzy. Go and C are only zero dependency once you have their
platforms installed (the OS). The JRE is only a little on top of that, ships
with some systems out of the box, and is generally ubiquitous enough that you
can probably rely on it being present it over a particular OS being present.

Ita not _really_ zero cost, but neither is an app that only has binaries for
an OS you don't run.

