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:
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.
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.
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.)
Java without JIT is useles for anythingbigger then hello world:(
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.
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.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
