As you all have probably noticed, work on the Japhar integration is
coming along fine now. I have finished the java.lang interfaces except
Thread and ThreadGroup (though not their Japhar implementation yet). I am
currently moving on to create the java.lang.reflect interfaces and I am
coming up against some annoying design constraints. Field, Constructor and
Method all have more VM-specific methods than non-VM-specific methods;
additionally, there are a few good reasons for VMs implementing the classes
(Field,Constructor,Method) themselves, not the least of which is more
control over the mapping between the internal object and the
Field/Constructor/Method object.
I would like to modify the proposal a bit: the VM implements the VMXXX
classes we have talked about already, plus it implements java.lang.Class and
java.lang.reflect.Field/Method/Constructor. Possibly Thread will benefit in
the same way and thus be included in this list.
This provides two benefits: (a) since these classes are mainly
VM-specific anyway, this will avoid unhelpful bloating, and (b) it will
allow smoother linkage between internal VM constructs. I see no drawbacks
except that they will have to implement some code that isn't VM specific;
since there will be a reference implementation to work off of, that
shouldn't be any problem.
I will, as before, provide a reference implementation (especially for
java.lang.reflect, since the reference implementation is basically done
already), and I will make it easy for them to modify for their specific VM.
What does everyone think? If I don't get replies, I'm just going to go
ahead and do it that way.
--John Keiser
