Maybe they bookmarked to see if there'll appear fun stuff later, it's still pretty much in the gruntwork phase of adding definitions/loading/basic interpretation to Rust. (Not working on any official projects myself but the experiments I did was in C or Java itself and with the latter you get tools like ASM doing gruntwork quickly)

One funny/annoying part of implementing a Java runtime is that you want mostly coherent handling of basic classes like Object, Class, String,etc.. (don't want tons of special cases in a JIT,etc) but the reflection data that defines Object and Class contains String's (That inherits from Object for a fun circular dependency).

For the most complete runtime I did (supported basic reflection,etc) I went with faux-object's,strings,etc when starting up created from C definitions that mirrored the real object shapes and then once far into loading walked the heap to modify the faux-objects to point the vtables to the actually loaded types for those classes.

Why would they? The direction for safer JVM research is to implement JVMs in Java, which has the advantage of being both memory safe outside a few tiny core areas (same as rust) whilst having cleaner code than the Rust impl (none of these problems with lifetimes).

See here: https://github.com/oracle/graal/tree/master/substratevm/src

Many of the safety benefits of Rust disappear once you start JITing machine code and jumping to it...