41–50 of 117 posts
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
Does it have cross platform Hi-DPI support? No.
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
> 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.
Debugging symbols are over 50% of most Go binaries I see, and you don't even need them to get stack traces from panics.
Combined with `upx --ultra-brute`, you can get static Go binaries down to about 12-15% of their plain `go build` size in my experience. (This also assumes CGO_ENABLED=0)
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.
It's frustrating how we're wallowing in problems that had already been solved for most of my career.
I'm unfamiliar with the state of the art, but could this make it possible to target iOS with a bundled JVM?
No.
As others have pointed out you could compile the Java code to native code before submitting the app, the way C# apps are put in the store.
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?
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…
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…
>tears down the barriers to desktop app development Yes, then it replaces them with the barriers to web app development.
Having a beautiful, easy to develop, and easy to maintain native stack means nothing when you don't have an answer to, "How do we then reuse our code in a browser?".
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.
End result: install nine apps, end up with three variously outdated copies of the JRE, none of which benefit the tenth app I install. It's frustrating how we're wallowing in problems that had already been solved for most of my career.