Yeah could be. I was just thinking that organizationally being part of OpenJDK sounds like a big thing and pulling back from that sounds like a reversal of a big thing. I'm sure the team wasn't extremely happy about it.
That move was much more reflective of the organizational politics inside Oracle as much as the tech itself. Graal turned into a separate (some might say competing) implementation of the Java platform, with its own unique vision and entirely separate teams, rather than simply feeding code into OpenJDK via its own processes.
Swapping out a part of a JVM as critical as the JIT compiler with a from-scratch rewrite would be a tremendously difficult and risky project even if the rewrite was done by the exact same team. Doing it when the rewrite is in a different language, all the knowledge is in a different team, in a different part of the company organizationally, in different offices and parts of the world, and also their implementation strategy to eliminate performance drops involves a completely different JVM implementation (SVM-in-HotSpot) ... well, the maintenance, budgetary and training complexities of that alone make it a tough one to digest.
I'm very hopeful they'll eventually figure out a path forward. It doesn't make much sense for Oracle to maintain three different JIT compilers (C1, C2, Graal). The biggest sticking point technically is probably the need to use native-image to produce libgraal. It'd be kinda weird for OpenJDK/HotSpot to ship two different JVMs, one that's used to implement the other. If they can find a way to AOT compile libgraal with acceptable performance, without a reliance on native-image, that'd probably be a good next step.
