61–70 of 76 posts
Earlier quoted context omitted.
Depends on how much effort, like on C and C++, you are willing to put into PGO metadata for the compiler and linker.
Even if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.
Earlier quoted context omitted.
IBM's J9 had AOT for a long time too. I wonder how JEP 544 compares.
IMHO the most interesting feature of OpenJ9 is the compile server. One node decides to optimize, sends over the traces, and the compile server sends optimized native code to all nodes. Or a new node joins and could be brought up to speed within a very short time.
Excelsior JET did that 25 years ago: https://en.wikipedia.org/wiki/Excelsior_JET It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.
The JRockit JVM had it already 20 years ago, and the company was even bought by Oracle shortly afterwards.
A little late, isn't it? .NET has had this for over 20 years (pre-compile).
Java is an ecosystem like C and C++, there were always multiple implementations to choose from, some of them required money for the goodies like AOT.
Earlier quoted context omitted.
> so long as you can live without third-party libraries that don't support AOT. Yes, and that’s a significant limitation in the Java library and framework ecosystem.
But the possibility of AOT compilation is what drives libraries to support it. That's why .NET libraries are adapting over time to support AOT.
Earlier quoted context omitted.
What would be in your ideal tool? I have a company that makes Conveyor, which is very good at distributing JVM apps. It's primarily meant for desktop apps and replaces jpackage with something that can cross-build, make apps self-updating, auto-minimize the bundled JDK and so on. Adapting it for servers is something I think about sometimes, and in fact it does already support that to some extent, but it produces debs…
My ideal tool would be less tooling, which I know is not a great answer. But what I mean by this is that I can probably cobble together a build pipeline that handles most of this stuff if I spend enough time working with Gradle. And the reality of Java's popularity in the enterprise means that its build tools generally orient around builds that can be crazy and bespoke and so immense flexibility is usually needed. I…
Native Image does produce single binaries in many cases, but what we need here is a much better tool in general. Actually I'm working on one right now, although it's not JVM specific. Want to take a look?
Earlier quoted context omitted.
But the possibility of AOT compilation is what drives libraries to support it. That's why .NET libraries are adapting over time to support AOT.
EF Core and F# still don't fully work, neither do the GUI frameworks, with exception of the buggy WinUI, mostly because it is all COM/WinRT underneath.
By "the GUI frameworks" I assume you mean Microsoft's GUI frameworks. They're all basically abandoned or just bad. Use Avalonia! It's better, cross-platform, and supports AOT!
Earlier quoted context omitted.
EF Core and F# still don't fully work, neither do the GUI frameworks, with exception of the buggy WinUI, mostly because it is all COM/WinRT underneath.
EF Core heavily relies on reflection so that's not really a surprise. F# not working surprised me but apparently the main thing is its `printf` depends on reflection. By "the GUI frameworks" I assume you mean Microsoft's GUI frameworks. They're all basically abandoned or just bad. Use Avalonia! It's better, cross-platform, and supports AOT!
F# is improving on .NET 11, but still not fully there, as contrary to the rest of .NET, it is mostly community driven.
Most Microsoft shops only consider Microsoft GUI frameworks, regardless of the great work done by Avalonia, and Uno as well.
As for being bad, they surely are much better than most competitors from other ecosystems, unless we're adding Delphi, C++ Builder, Qt into the picture.
I had projects with Java on the server and Microsoft GUIs on the desktop, for example. Swing and JavaFX are also quite good, however require additional programming for what Forms and WPF do out of the box, unless one is willing to pay for something like JGoodies.
Earlier quoted context omitted.
Are you describing jpackage? I'm not sure how you would make it less bespoke, given you are essentially creating a Java runtime for your program. Maybe the Java folks could tree-shake the runtime for you so you wouldn't have to care about their weird module system, but it's not the worst thing to learn.
Jpackage or jlink should be extended to support creating AppImages.
Earlier quoted context omitted.
Even if you can gather that PGO metadata a running application won't be able to adapt to changes in that data.
It works well enough for systems software written in C and C++, where Java still remains a niche option, even when it could deliver.