Demi Marie Obenour wrote:
> I haven’t written Java in years, but my understanding is
> that AOT compilation has three major advantages:
>
> 1. 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.
> 2. 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.)
> 3. 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.
> In short, an AOT-compiled application behaves much more
> like one that is written in a native language like C++,
And it turns out a lot of Java applications do not actually work that way.
Which is why GCJ had a second mode, where, instead of building a binary with
gcj just like with g++, you would instead AOT-compile every Java class
individually to a .so in a special directory, then run the Java application
"the Java way" with gij, and gij would behind the scenes look up the AOT-
compiled classes to speed up the interpreted run. IMHO a very ugly hack, but
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
in that mixed mode.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
