This is definitely an improvement for Java, but it leaves me with a few thoughts as someone who has done Java professionally at times, but also professionally lived in other ecosystems including C++/Qt, Python, Ruby, Golang, and of course node/JS.<p>1. Setting up a project is still a pain in the butt. Tools like Gradle are a nice improvement over Ant (and some would say maven), but still most people don't even understand them. You have some serious reading ahead of you if you want to set something up that isn't already templated somewhere for you. You can lean on an IDE for sure, and for most Java devs this is probably a no-brainer. I'm weird in that I don't like magic. I prefer to know what the tool is doing on my behalf, and the Java IDE world is so complex that it isn't practical to learn that unless you're in the ecosystem for years. Then dealing with weird exceptions from the JVM can be maddening.<p>2. The Java world moves slowly. It could reasonably be years before many shops transition to Java 9, when you would actually realize the benefits of this in your work life.<p>3. So much Java runs on the server side anyway, where executable size and entrypoint doesn't really matter that much. Because of this, it may only be a small subset of Java shops that really get into Java 9/Jigsaw and iron out the bugs, and create tools/tutorials for others.
Is worth mentioning that SubstrateVM (<a href="https://github.com/graalvm/graal/tree/master/substratevm" rel="nofollow">https://github.com/graalvm/graal/tree/master/substratevm</a>) is now open source, which does whole-world AOT compilation to produce a single executable or shared library. It does have substantial limitations (eg no runtime class generation/loading), so it might not be suitable for every project
The author misses the point when he says this might help Java regain share in the space of DevOps tools which is currently mostly Go.<p>The problem is not artifact size but the JVM slow start-up time. This is made worse by almost all Java frameworks that by definition do all their own stuff before passing control to your real app code.<p>Such executables are not something you would put in a loop in a shell one liner, and that is the space for command line utilities Go has occupied successfully.
Now combine it with JavaFX and we can have reasonably-sized cross-platform GUI apps again.<p>Yes, you can compile a QT or a GTK app for every platform, and use e.g. Python or Go to write the cross-platform part + package it into a single file. It's still as many files as you have platforms.
How are .so, .dll files handled during Java packing? This is more open question, but say you have one ".exe" file. Now you need to extract the DLL in a place, and make sure everytime it's the right one (gets tricky if the tool is ran simualtnenously, like spawned from a build process).<p>While I was at Google, instead of having multiple .so files, the main launcher was a C++ binary, and all external C++ dependencies were linked into it (that's it if you have the source code), then you didn't need that.<p>I guess now it's up to the BUILD system to achieve that, where if you have more flexible BUILD language you can instruct everything to go in the main launcher file, then have all the .jars into one, slapped at the end of the file.<p>At the end, ship or update only one binary to your service, desktop machine, etc.
> Using Java 9 Modularization to Ship Zero-Dependency <i>Native Apps</i><p>> [...]<p>> and superior to web-hybrid options like Electron<p>How is Java or Electron (JavaScript+WebKit) considered <i>native</i> nowadays?<p>Please use native APIs, so my laptop can actually hold 10h load on battery.<p>edit: can we remove <i>native</i> from the title?
Dunno if I'd call Java <i>native</i>. This is more like zero-dependecy Java apps — aka, you don't need to pre-install the JVM (and its "optional" adware on Windows).
"and superior to web-hybrid options like Electron"<p>Superior exactly in what way? Electron allows access to an enormous audience of developers and the web ecosystem. You really can't compete with that and would be silly to try at this point.
Anyone notice that Java is suddenly cool thanks to Kotlin?<p>I haven't done much more than dabble, but it was an enjoyable dabble. Unlike vanilla Java.<p>It even compiles to JS with a relatively small-ish runtime. It's big enough to cause problems embedding it, but it's small enough to be workable.<p><a href="https://github.com/JetBrains/create-react-kotlin-app" rel="nofollow">https://github.com/JetBrains/create-react-kotlin-app</a>