"John Keiser" <[EMAIL PROTECTED]> writes:
> Entire classes: java.lang.Class, java.lang.reflect.* (there are
> specific optimizations a VM could make that would speed reflect up,
> and Class is ... well, you know, it's Class!).
We shouldn't leave out entire classes -- at the very least we should
stub and document them. Parts of Class can be implemented in Java --
for instance all the Resource dispatch calls to ClassLoader. We
should be as VM independent as possible.
Do you really want to ditch your entire reflection implementation?
> We write generic, well-commented skeletons for the VM-specific
> things to make them easy to implement by a VM. Then the VM maker
> writes the functions and gives us the modified c and h files and the
> java files and we put them into a directory for that VM
> (vm/japhar-1.1/java/lang, vm/japhar-1.1/java.lang, etc., etc.).
I don't believe this is a good way to go about it. It would make more
sense for the VM specific stuff to be shipped with the VMs. If we
ship the VM specific stuff, then we might have to do a new release of
Classpath anytime a new version of a VM is released.
Maybe a better idea would be to create a package called "gnu.vm" in
the Classpath distribution. The package would consist of all the
interfaces which a particular VM would need to implement in order to
support Classpath.
thoughts?
--
Paul Fisher * [EMAIL PROTECTED]
