It looks like Japhar will be about ready to begin the merging process
in about a month (based on the maturity of code).
I don't know if you all have thought much about merging Classpath and
Japhar, but it's going to be a bitch, as far as I can tell. Things like
java.lang.Class, ClassLoader, etc., will have to be built by us; there are a
number of control issues involved: for example, java.lang.reflect. He who
writes java.lang.reflect.{Field|Method|Constructor} must write
java.lang.Class, because it needs to be able to call getMethods, etc...
(Well, not anymore, because whoever wrote it could call
(*env)->ToReflectedField, etc., and we could just control those ...)
If we control java.lang.Class, it will be a nightmare. Japhar, I
believe, has a pointer to the jclass object from the internal class
structure and a pointer to the internal class structure from the jclass
object. We can't control that; how can we work with them on it, though?
Certainly we can give them an API, but we have to remember the cost of APIs.
Function calls, especially in the very core of the system, are expensive
beasts.
Might be better to create an include file with macros for each
different VM ... no matter what we do, we have to make it fast.
Also, it looks like there are issues with String as well (obviously,
from the fact that we can't run it under JDK). I am guessing JDK must use
String's internal format the way it apparently uses FileDescriptor's. I
fixed a few minor bugs in java.lang.String today, but nothing major.
Anyway, is Japhar going to transition to us from Sun, or try to keep
Sun support as well as implement Classpath support? We're going to have to
think about these issues and work with them on it. This is our first
supported VM, and we need to make the process as smooth as possible for it,
so that next VM (Kaffe?) around, it is that much easier.
Also, to make the transition as painless as possible, we need to finish
java.lang and java.util. Things like java.lang.Class need to be written,
just don't fill in the methods you can't fill in yet. That way the
transition can be made with a minimum of pain. No need to shy away from
writing the entire class because some of it is unimplementable.
--John Keiser
