Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Java 9 Modularization to Ship Zero-Dependency Native Apps

steveperkins.com

Post reply on HN
Print view View original

71–80 of 117 posts

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

#71

Post by camus2 »

nerdponx wrote: post #67
firdak wrote: post #59

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

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

Go runtime is included in the executable. C or C++ do not automatically do that when writing a simple "hello world" and compiling it into an executable. stdio isn't statically linked by default.

And when rid of debugging symbols, even when importing the fmt package :

    package main

    import "fmt"

    func main() {
        fmt.Print("Hello World")
    }
go build -ldflags "-s -w" hello.go

is 1.3MB .

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

#72

Post by joosters »

c_shu wrote: post #68
nerdponx wrote: post #67

Earlier quoted context omitted.

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

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.

(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 
   
   int main( int, const char *[] )
   {
      std::cout
'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.

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

#73

Post by Sophistifunk »

Pyxl101 wrote: post #61
ZenoArrow wrote: post #22

Earlier quoted context omitted.

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?

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…

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.

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

#74

Post by unscaled »

c_shu wrote: post #68
nerdponx wrote: post #67

Earlier quoted context omitted.

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

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.

It's a matter of platform and the libraries that you're using.

After all, back in the days we had 360k floppy disks, and executable written in C which did much more than just printing out "Hello world" would fit comfortably into less than half of that.

Modern C and C++ runtimes are bloated, because a 2MB executable isn't considered huge anymore and dynamic linking is common.

But you can have a 5k static executable printing "hello world" on Linux if you just trade in your stdlibc to musl. People have also managed to use musl with Rust to produce pretty small executables: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

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

#75

Post by jrs95 »

cyberpunk0 wrote: post #52
ssijak wrote: 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…

Probably not many. They are too busy developing instead of over obsessing over small performance gains

It's not a small gain for me, it's basically a necessity for keeping RAM low enough. I have 16GB on my work machine, and that's barely enough.

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

#76

Post by crispinb »

erikbye wrote: post #32
supergreg wrote: post #26

Earlier quoted context omitted.

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.

I was curious as I've never found a standalone visual git client I liked as much as IntelliJ's integrated one. So I downloaded it, found it was 1/4 of a GB and wouldn't look at a local repo without logging in to a web service. Deleted.

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

#77

Post by jrs95 »

ssijak wrote: post #15
capelio wrote: 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…

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…

I'm using JetBrains IDEs now instead. They're definitely not lightweight, but it's built in functionality is generally a lot more stable than what I get with text editors + a lot of plugins.

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

#78

Post by i386 »

blinkingled wrote: post #31
i386 wrote: 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.

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.

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

#79

Post by blinkingled »

i386 wrote: post #78
blinkingled wrote: post #31

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN