On 6/2/23 01:09, Kevin Kofler via devel wrote:
Demi Marie Obenour wrote:
I haven’t written Java in years, but my understanding is that AOT compilation has three major advantages:
- It reduces the size of total deliverables because the final executable only includes the libraries it needs.
This may be true for real AOT compilation where the result is really independent of a JRE (e.g., what GCJ, which is no longer maintained, used to produce by default), but if the AOT compilation requires you to bundle the whole JRE (and that is the only case where having a statically vs. dynamically linked JRE matters), the total deliverable size is going to be much larger.
Interesting discusson, indeed!
The aot should create portable minialistic image. If you build it from dynamicaly linked JDK, iirc, the image will not be trasnferable (as it will still require those dynamicaly linked libraries). As fot rhe size, werer the goal of minimalistic was there, it si proving to not be exactly true, and final iage is quite big.
- It is the _only_ way to have decent performance on platforms where JIT compilation is forbidden.
That is also irrelevant in this thread: If it matters how the JRE is linked, the AOT-compiled output includes a bundled copy of the GNU/Linux JRE (otherwise why would it matter?), so it will only run on GNU/Linux, which is NOT a "platform where JIT compilation is forbidden". (There is only really one such platform, iOS with Apple's totalitarian app store rules.)
Java without JIT is useles for anythingbigger then hello world:(
- AOT-compiled apps start up faster and use less memory.
That part may be true, but there too, if we are talking about a solution that includes bundling the JRE, I doubt it.
This is actually the only reason I'm finding as really valid. In world of micro services, which even run with epsilongc, this is saving enourmous resources.
necessary because Java applications are NOT designed to be built like native applications (e.g., pure AOT compilation without a JIT and/or interpreter fallback cannot handle classes loaded at runtime, such as dynamically generated or downloaded class files). Many applications worked with GCJ only
I agree that java is not designed tobebuilt lilenative app, and that is why gaarl/mandrel and qaurkus are so terribly complicated. Future will show.
Thanx! J.