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.