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

61–70 of 117 posts

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

#61

Post by Pyxl101 »

ZenoArrow wrote: post #22
tpolzer wrote: post #16

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

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

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

#62

Post by camus2 »

virmundi wrote: post #38
camus2 wrote: 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 l…

> Binary size for a hello world app means little to nothing.

I'm just quoting the original article. If you want to get mad at someone be mad at the OP. The whole point of the post is executable sizes.

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

#63

Post by wstrange »

0xbear wrote: post #60

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

The bundle includes the JRE.

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

#64

Post by NikolaeVarius »

richardwhiuk wrote: post #37
aaomidi wrote: post #14

Earlier quoted context omitted.

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?

Slack takes up 1.3 gb of RAM if I don't restart it at least once a week

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

#65

Post by kbenson »

0xbear wrote: post #60

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

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.

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

#66

Post by profalseidol »

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…

I can be, for very small very cheap devices.

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

#67

Post by nerdponx »

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.

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

#68

Post by c_shu »

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.

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.

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

#69

Post by [deleted] »

pjmlp wrote: post #21
camus2 wrote: 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.

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/

[deleted]

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

#70

Post by [deleted] »

morecoffee wrote: post #20
camus2 wrote: 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.

print() is a nonstandard function and will be removed eventually.

[deleted]
Post reply on HN