Live data from Hacker News

Using Java 9 Modularization to Ship Zero-Dependency Native Apps

steveperkins.com

31–40 of 117 posts

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#31
post #28

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.

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.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#32
post #23

Earlier quoted context omitted.

Discord is great

So is gitkraken. But I assume these apps have spent a considerable amount of time in optimizing electron, which not everyone can do.

While some may find GitKraken visually pleasing, it can't be used for big repos; didn't even manage to open a few of the ones I tried.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#33
post #18
post #15

Earlier quoted context omitted.

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 bet…

Electron pop culture made me buy Sublime Text.

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

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#35
post #2

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…

Electron sits in the same hybrid space as Cordova/Phonegap, and will suffer the same fate once React Native, or something similar, starts eating its lunch.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#36
post #13

Earlier quoted context omitted.

But that 200KB isn't a standalone executable. The Go example would be a lot smaller if it just distributed some unlinked object code with no runtime.

True. The JVM is big. I've been meaning to try Golang one of these days, I see it as Java's spiritual successor

I tend to view it more as a regressor. Golang is a conservative retrenchment towards Java pre-1.5 in a lot of ways. (And that may be fine for some use cases; I get the appeal even if I think it's misguided.)

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#37
post #14
post #2

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…

Yes, but it's electron. I've honestly seen only one properly written Electron app and it's VSCode. Everything else electron sucks. VSCode is not great either but it's much better than say, Atom or Slack.

Slack?

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#38
post #5

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

Hey! You win the worthless example competition! See the front desk for your prize. How about comparing a full stack, monolith app in Java vs Golang? While you’re at it, don’t just compare binaries. Compare how well it handles concurrency. Compare how well it handles templates. Or how smoothly it handles DB interaction. Then look at all this and compare the population of Golang vs Java devs. Compare how well you can leverage existing language knowledge while working on a major mobile platform too like Android.

Binary size for a hello world app means little to nothing. I can beat that with Bash: echo “hello, world!” Compare to real applications.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#39
post #25

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

It is possible using an AOT compiler for Java, like Codename One or Robot VM.

So far Oracle has shown little interest into integrating such features into OpenJDK, but the ongoing efforts to add AOT compilation to it, might become a possible solution.

Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps

#40
post #25

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

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.

There are AOT native Java compilers for iOS, the majority just tends to ignore them.
Post reply on HN