While everyone is excited about how this helps desktop app development, this is also going to simplify server deploys. If you've got a full java stack, you won't need to do anything to provision a server.
Using Java 9 Modularization to Ship Zero-Dependency Native Apps
11–20 of 117 posts
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#12Earlier quoted context omitted.
You can get under 200KB in Java easily by using proguard or similar to strip unused code from your dependencies.
Sure, but I didn't apply any specific code optimization or third party tool here.
Progaurd is default on Android and some other environments, it's not anything exotic.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#13> 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.
You can get under 200KB in Java easily by using proguard or similar to strip unused code from your dependencies.
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.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#14Even 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.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#15Even 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 better than Atom) because I don`t want to have my text editor eat 500mb ram to open 1 medium file and crash on large ones. Same for Slack and other Electron apps. And it is not even funny to see dev console when some Atom plugin or whatever crash. I`m interested how many devs also ditched this two editors ONLY because of Electron bloat.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#16Does it have cross platform Hi-DPI support? No.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#17I want to use JavaFX to develop cross-platform apps but I feel JVM uses too much memory even for little things. It's been a while since I've used Java to program, has the memory situation changed? or are there any other solutions for lowering the JVM memory usage?
Default heap size is over-generous in most JVM implementations, experimenting with smaller settings is the solution.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#18Even 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…
Electron pop culture made me buy Sublime Text.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#19I want to use JavaFX to develop cross-platform apps but I feel JVM uses too much memory even for little things. It's been a while since I've used Java to program, has the memory situation changed? or are there any other solutions for lowering the JVM memory usage?
Apparently lack of memory isn't something that affects Electron popularity.
Java applications use much less memory, unless their coders weren't paying attention during algorithms and datastructures lectures.
Re: Using Java 9 Modularization to Ship Zero-Dependency Native Apps
#20> 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.