4 ms·
That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage
by layer8 25d ago
That would place significant limitations on the applications that can be compiled. As the JEP explains: “Features such as dynamic class loading, dynamic linkage, dynamic dispatch, and dynamic reflection bring vast expressive power, and have been fundamental to the platform's success. HotSpot handles these features naturally, while static compilers struggle with them. Even heroic amounts of static analysis cannot make up for the fact that these features require many decisions to be made at run time. Implementors of static compilers for Java code have therefore resorted to incompatible constraints, such as closed-world assumptions, and to putting significant burdens on developers, such as having to identify in advance the classes eligible for reflection.”
Therefore I don’t see AOT-only becoming an integral part of standard Java in the foreseeable future.
- java-man 25d agowe are not talking about fully supporting dynamic loading, because it's not needed in all the cases, and in some cases, the list of allowed classes in the application can (or must) be limited. i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
- samus 24d ago> i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++. What is the objective here? Startup latency or throughput? Both will be vastly improved by JEP 544.
- jasomill 25d agoIt works pretty well for greenfield projects on .NET, so long as you can live without third-party libraries that don't support AOT. Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch. Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.
- layer8 25d ago> 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.
- Rohansi 25d agoBut the possibility of AOT compilation is what drives libraries to support it. That's why .NET libraries are adapting over time to support AOT.
- pjmlp 23d agoEF 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.
- Rohansi 23d agoEF 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!
- pjmlp 23d agoWell, they had enough time to refactor EF Core to use code generators. 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.