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

101–110 of 117 posts

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

#101

Post by adamhepner »

phreack wrote: post #3

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!

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?

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

#102

Post by ZenoArrow »

Sophistifunk wrote: post #73
Pyxl101 wrote: post #61

Earlier quoted context omitted.

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.

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?

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

#103

Post by alexasmyths »

gdfhhgddhjj wrote: post #57
cyberpunk0 wrote: post #54

Earlier quoted context omitted.

It offers access to file system and system resources as well as multi platform build support. Developers like all people will whine over anything. For students and indie devs who have little time, support, and resources things like electron are great

Right, but does eg slack actually use any of that? It’s not a great native client by any stretch—it doesn’t use a native UI, it’s not particularly snappy, and it doesn’t do any special integration. So, it seems that electron is mostly a way to distinguish certain sites from others, not that they provide a better experience. Granted I do like the distinct app icon. But electron should mean more than that to qualify as…

What electron gives Slack is A) local install and B) proper notifications.

So Slack gets an icon on the homescreen and possibly offline notification + notification integration with the OS.

That might be pretty limited from a technical perspective, but it's a massive product thing from a product perspective.

Also, it's possible they may use file access for caching/storage etc..

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

#104

Post by [deleted] »

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.

[deleted]

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

#105

Post by harrygeez »

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?

For what's it's worth, I've written Java 8 on macOS and it 'just works'. I didn't have to do anything to make it look good in hidpi.

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

#106

Post by KGIII »

always_good wrote: post #99
KGIII wrote: post #82

Earlier quoted context omitted.

Another anecdote; your comment is the only one I've ever noticed that appears to be defending Slack. From an outsider looking in, I'm not sure why it is so popular.

It's popular because technical superiority isn't why people use software. For example, Spotify eats 100% CPU if I leave it open for 24 hours yet I don't think I've met someone in the last year that doesn't have Spotify running on their computer.

If it helps, I don't have Spotify.

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

#107

Post by Can_Not »

_sh wrote: post #35
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…

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.

There are some ReactNative alternatives calling themselves "native" that are only "native looking css in a webview". The future will probably only get more ambiguous.

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

#108

Post by kryptiskt »

bmn__ wrote: post #100

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

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

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

#109

Post by SOLAR_FIELDS »

crispinb wrote: post #76
erikbye wrote: post #32

Earlier quoted context omitted.

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.

I still haven't found anything better than IntelliJ's triple column view for resolving merge conflicts. Is there anything similar in a more lightweight editor?

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

#110

Post by icebraining »

SOLAR_FIELDS wrote: post #109
crispinb wrote: post #76

Earlier quoted context omitted.

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.

I still haven't found anything better than IntelliJ's triple column view for resolving merge conflicts. Is there anything similar in a more lightweight editor?

If you don't mind having it separate from your main editor, Meld is great.
Post reply on HN