Are these basically statically linked jars?
But yes, it is just like including files in your classpath (and making sure they end up in the jar), then serving them from a Netty endpoint or something.
It is only a matter of buying one of the commercial JDKs, or if doing GPL stuff use the open source license from ExcelsiorJET.
Those not willing to pay and already on Java 9/10, running on Linux x64, can play with the initial AOT support.
A JAR is meant to run on the JVM. There is no such thing as a "statically linked jar". The process you're referring to is more like compiling bytecode to assembly, you're converting a JAR, a thing meant to run on the JVM, to native machine code (with assembly as the step in between).
> it's only a matter of ...
Yeah, it sounds simple in theory, but somehow I don't find many projects these days that use these commercial JDKs to generate VM free assembly. In fact, I don't even know one big tech company that does so -- maybe you could enlighten me.
> Those not willing to pay and already on Java 9/10, running on Linux x64, can play with the initial AOT support.
So just about the newest version of Java just got initial support? Cool. Well this brand new community-led thoroughly open-source language has this as a core tenet, and supports compiling to many platforms very easily.
Kudos to Java for getting better, embracing a more open development methodology (I think this has been the case since 8), listening to the community more about which features to include, but when compared to projects that took a fresh look at all these concepts, and started with the open community-based approach, Java doesn't compare (except in terms of speed, JVM is pretty heckin' fast).
Ah, and if you happen to own an Android phone running version 6.0 or newer.
The free beer version of Java never supported AOT because Sun was religiously against it.
The community never managed to gain enough mindshare to keep gcj going, which was used by Red-Hat to ship native compiled versions of Eclipse, Tomcat and JBoss.
Since Oracle thankfully has another opinion on AOT, they have a long term plan to bootstrap Java and remove C++ out of the equation.
Also, Android went from Dalvik to ART right? Those are both still VMs? Latest android looks like ART + JIT, but you can't AOT a JIT (that's the whole point of doing it Just In Time)?
Maybe I should take a look at Java 9/10, but if an employer isn't requiring it, and library support is somewhere near similar, I'm definitely considering doing the project in Rust first, then Clojure, then Frege, then Java 9/10.
Outside of the insane wealth of libraries that exist as a result of no one really having a good cross-platform choice for the last few decades, I don't think I'd choose plain Java for a project today. The JVM, maybe, but not plain Java on top of it. Luckily, I'm not the only developer out there, since there are tons of people who love java are still supporting it and using it, making cool things with it, and pushing it to be better.
Until version 5.0, there was only Dalvik, a register based VM with a very basic JIT compiler.
On version 4.4, ART was introduced, but you had to explicitly enable it and many OEMs did not had it available anyway.
ART was a pure AOT compiler, at installation time on-device.
Given that it was taken hours to recompile everything when updates came on phones with lots of apps, Android 7 introduced a multi-mode interpreter/JIT/AOT toolchain.
On 7 and later, when an application starts for the first time, the interpreter written in hand optimized Assembly is executed, then control is given to the JIT, which in turn makes use of PGO.
A background AOT compiler takes the PGO data generated by the JIT and creates an optimized AOT binary for the application.
The next time an application is executed, the AOT compiled binary is used, until there is some kind of change, like an update or unexpected execution path, that requires a recompilation to take place.
http://openjdk.java.net/jeps/295
Basically Java AOT is half-assed solution like so many other Java solutions e.g Java GUIs, Java build tools, Java generics etc etc.
Either one replaces the engines in mid-flight, or parks the plane with perfect thought out solution.
Dalvik was a JIT VM. Then, for Android 5.0 (Lollipop), Android moved to AOT compile code (On installation and ROM upgrade, which is why if you ever updated Android then, you'd be sitting and waiting for a few minutes while Android optimized apps).
Then recently (I don't remember if it was for Marshmallow or Nougat) Android went back to a JIT VM on install, followed by a background AOT compile. This way installation goes faster (it doesn't have to compile everything right away), ROM upgrades go way faster (you don't have to AOT compile tens to hundreds of apps before being able to use your phone), and Android can do guided optimization during AOT (it knows which hot-paths were taken).
Sound exactly like the kind of environments were all kinds of horrible crap are used. Doubly so with the mention of IBM.
I just mentioned those, because they have Java code in production, with soft-real time deadlines for weapon targeting systems of a few milliseconds.
Usually the kind of stuff that gets mentioned that GC enabled languages aren't capable of.
It is all a matter of budget and the army has lots of it, which incidently is what allowed boring stuff like the Internet to exist.
Sure, I don't have a beef with either (although someone could go non-JVM to get either AOT and/or real-time guarantees in a better form perhaps).
But I don't think "the X and Y army uses it" serves as proof that a technology is mature.
It's not like the army doesn't have all kinds of non-critical applications, and all kinds of legacy crap and modern crap apps lying around, doing some thing or another.
It's like saying "Facebook uses our app X" as proof of maturity, when the use could be in some horrible experimental project, that Facebook tried and semi-abandoned, or is the product of some engineers "20% time" stuff...
French radar system for ballistic missile tracking and measurement.
http://www.militaryaerospace.com/articles/2009/03/thales-cho...
Aegis Weapon naval defence system, deployed across US Navy cruisers
http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aoni...
USS Bunker Hill ballistic missile defence system weapons control
http://www.militaryaerospace.com/articles/2010/04/aonix-perc...
Thanks for mentioning our product, but I have to make a few corrections:
First, the Excelsior JET Runtime license is sadly not GPL-compatible. Also, you cannot use it to target embedded systems, unless you buy Excelsior JET Embedded and pay royalties, though we are currently weighing the option to switch to OpenJDK to eliminate the latter.
Second, the Standard Edition is free even for commercial use (the above limitations apply).
Finally, other editions are available at no cost for use in public non-commercial projects. It does not matter whether the (software part of the) project is open source or not.
See https://www.excelsiorjet.com/free for details.