(1) Native methods: For us, native
methods are (1) lower performance and (2) can't be used early in the VM
booting process. This is the primary reason for java.lang.Object,
java.lang.reflect.Field, java.lang.reflect.Method, java.lang.reflect.Constructor.
(2) java.lang.ref.*. Very little
code in these classes that isn't VM specific. Don't see any reason
why classpath should be expected to provide them, as they are really unlikely
to be useful to anyone. Yes, Jikes RVM does implement this stuff...you
have to do at least weak & soft references if you want to run larger
server-side applications.
(3) java.lang.Class. If the Class/VMClass
redesign with a VM-specific instance of type Object goes through, then
we might be able to use it.
(4) java.lang.Throwable. I don't
see any hope for us ever using the classpath implementation. Handling
exceptions is pretty delicate, and one of the implications of our entire
VM being written in Java is that it is even more delicate than in a C based
VM. We have lots of Jikes-RVM specific stuff here to deal with decent
stack trace printing early in VM booting & in other cases where the
VM is "sick" or in a funny state and operating purely in Java
won't work.
(5) java.lang.Thread. We do m-n
threading and some other strange stuff. Our thread class is kind
of strange and really intertwined with other aspects of the VM. If
we were starting from scratch, I think we could use the Thread/VMThread
currently in classpath, but it would be a lot of work to retrofit.