There are several features in the platform for dynamic code generation that are very hard to make work in an AOT scenario.
Graal native gives up the benefits of JIT for fast startup. It might be a useful tradeoff for some but it is not a universal solution.
I think the next step for Java will be more people shifting to using ZGC which automatically releases unused heap back to the OS where the current default (G1) doesn't.
[0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...
You absolutely don't need to use a framework like micronaut. You do however need to understand what libraries you are using, and if/how they use reflection and dynamic class generation.
To the point of: if you want to deploy serverless applications and GraalVM requires you to write Java code that is so fundamentally different than what you have been doing for so long, why would you even stay with Java, you already lost much of the benefit of it being supposedly "the same language", and you may then just as well write your serverless application in Javascript or Python. Instead of using a far from mainstream solution like GraalVM.
I'm even wondering how obvious or subtle the bugs would be if I ever accidentally did something reflective in GraalVM.
I found this video very validating for thoughts I already had about how optimizing Java for use in AWS Lambda is not how I want to be programming Java: https://www.youtube.com/watch?v=ddg1u5HLwg8 What he lays out in this video makes me think back to doing my own memory management in C++. There's surely a place for that: high-level application development just ain't that place, in my mind.
(Myself I'm interested to see how well this handles Scala, since avoiding reflection completely is pretty much the norm there).
Spring, and Spring Boot most egregiously, work only to widen the gap between devs and ops. The developers have no idea what a Boot app is doing internally for 90% of its stack. The ops guys just want to stably deploy something that is well understood and supportable when it falls over. Not to mention the memory management headaches it introduces...
I moved away from JS early on in my career because it's mostly a disaster waiting to happen, but now the Java devs have the same potential to output a steaming pile of crap that they don't understand.
This is the biggest problem by far with Spring Boot. It’s not just hidden default settings or convention or configuration, it’s entire hidden applications.
Could you elaborate on this?
The dev team refused to accept responsibility as though they hadn't fought tooth and nail to use Spring Boot in the first place.
https://github.com/borkdude/babashka is a good place to start
(or https://github.com/taylorwood/lein-native-image if you are using Leiningen)
How so?
Whereas for me Spring Boot has the same feel as the bad old days of early Spring 3.x - lots of magical constructs that were impossible to understand unless you knew all the Spring specifics. A Spring Boot application will behave completely differently based on just which libraries happen to be on the classpath - the exact same code might start up a tomcat server when run one way and not when run another way - and has a whole host of new Spring-specific things that you have to learn if you're going to understand how your application is behaving.
GraalVM is two things. One is a regular but enhanced HotSpot. All existing Java code works on it. You can also run all the Truffle/Graal languages on it fast - it basically turns the JVM into a VM for many languages with good or great performance.
Then there's "native-image"/SubstrateVM. This can also run most Java code, including all code that uses reflection. Reflection isn't missing or broken on this platform, but by default it throws out the metadata you need for it and maybe the code (because it will appear unused). So you have to tell native-image what classes you'll want to reflect over at runtime so it keeps the data. This is well known to mobile developers who used ProGuard because it's the same; you have to say "classes matching these patterns need to be reflectable so don't optimise them".
You can't really have bugs caused by not setting these configurations correctly because if you try to reflect something you didn't pin you immediately get an exception telling you about your mistake.
The thing SubstrateVM cannot do, at least not until a later project that Oracle are working on is released, is run dynamically generated bytecode.
It's bytecode synthesis and plugin loading at runtime, not reflection, that causes the compatibility issues.
SVM/native-image has its place, but currently it's optimised for things like command line apps or servers that people constantly shut down and start up to try and save on huge AWS costs. Actual runtime throughput and latency will be far better on regular OpenJDKs, especially the latest ones with much better garbage collectors.
There is also https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...
nailgun doesn't solve it generally.
leyden is not released yet; its proposal into JDK future is validation of the approaches projects like GraalVM/Mandrel and Quarkus are doing.
Still today, jlink for the above modules won't work (not generating jmods, especially all those jakarta.xxx stuff) with original tool, imagine with GraalVM.
Framework vendors are betting on fact that most Java apps are HTTP/ORM/JSON plus metrics and security etc. So if framework provide transitive closure of these libraries and provide configuration to compile native, it will work.
For my purpose it does not work because I have many more dependencies which do not fit in above framework. Also I prefer to write my code directly with JDK and external libraries without any of these framework.