There are efforts to ensure that important workloads like ASP.NET Core work with it well. Due to AOT nature it's often not possible to make it require just a build argument switch, but it is still fairly easy nonetheless, in 90% of situations having to do with switching from reflection to source generation (like in the case of System.Text.Json) or solving statically not-analyzable patters of reflection (AOT supports reflection, just not emitting new code in runtime since there's no JIT!).
Well-written libraries that do not use reflection to generate new code in runtime do not require any changes and "just work". A lot of new code shipped is now written with Native AOT in mind to be compatible (with some exceptions, looking at you, SemanticKernel).
Still it's not practically usable and that's what counts for me. From what I understand it is plagued with the same issues as the C# AOT when it comes to reflection and therefore serialization. There is a whole list of other issues as well[1].
I think some of this issues can never be solved by the compiler alone but need to be addressed in the ecosystem. It would be important, for example, that the most common and important libraries dispense with reflection to play well with AOT.
Finally GraalVM is just a single project with its own specific agenda. If Oracle changes its mind about these goals tomorrow Java AOT will be dead once again.
These are the reasons I'm still not optimistic about Java AOT, even if GraslVM is really cool project.
