> From: Artur Biesiadowski [mailto:[EMAIL PROTECTED]]
>
>
> Here are few questions for you:
>
> 1) Are there any native methods for java.lang package ? They seem to be
> missing from native/ directory. Or is it vm creators responsibility to
> implement them all ?
>
There may be some native methods for java.lang, but in the current design
you will never write a native method for a java.* class. See the next
section for details.
> 2) What interfaces should vm implement to be classpath aware (except
> JNI) ? I've heard something about VMI, but all functions already have
> definitions - should they be overridden ?
>
The design for this is pretty close to settled. There will definitely be a
set of classes in gnu.vm that you provide, that the java.lang classes hook
into to do VM-specific stuff. With a good linker, this can easily be made
as efficient as if you provided a native method directly for a java.lang
class. Ideally, providing these classes will be everything the VM
implementor will have to do.
We are planning to get the kinks worked out with Japhar pretty soon, but if
you want to join in, I'd be happy to give you any info I have and help you
implement it for Chives. The number of methods and their specifications
will not change from now, but the name of the classes they are in may.
Thus, the churn won't be too bad if you want to go along for the ride.
> 3) Is there any way to easily replace parts of classpath with
> vm-specific code ? I'm thinking mainly about native_state (current
> implementation is state of art vm-independence, but some VMs may just
> want to implement pointer to native data in obj data, and thus save a
> lot of time to access them) and using native-native interface for
> java.lang,java.lang.reflect and java.io instead of JNI.
>
I have been hoping Japhar would do that, as well, so I have been thinking
about it. The best way will be to have a VM-specific version of
native_state, I think. That way, you just recompile the native libraries
for a specific VM and they automatically use either the JNI or VM-specific
version.
The best thing to do, IMO, is to abstract things like this native state
interface and have ambitious VMs provide their own implementation if they
want. Then, two different versions of classpath would work on your VM: the
generic one, and the Chives-specific one, which would be faster.
> 4) Fields in java.lang.Class are not a good idea. This class has to be
> treated specially by vm anyway, and there is a hell lot of native calls
> - saving 5 of them is not a bonus, but it can cause some problems to vm
> implementors; for example in chives we want to implement it as normal
> object, with native data after obj fields, and current design will force
> use to loose 12 bytes per class for nothing (as we would need to
> duplicate this 3 fields (with maybe exception of signers) anyway)
>
The fields that are in java.lang.Class are all there to save time when
accessing certain data members (pure Java access will be faster, and class
name and superclass will be called fairly often). The VM will not need to
be aware of these fields. I don't like VM dependence on the field structure
of a class. It gets messy. If you have a special need, though, we can
certainly talk.
As for the native data object, that's perfectly fine, and even recommended.
There will be methods for you to implement in gnu.vm.java.lang.Class for
getXXX(), setXXX(), etc. Any Java-side caching scheme Classpath uses in
java.lang.Class should be transparent to you. FYI, the only things that
will probably end up being cached are name and superclass.
> 5) What are these class signers, BTW ?
>
I have no idea whatsoever :) All I know is that it's an array of Objects.
I assume it relates to signed JAR files and security. Aaron will probably
know more once he finishes java.security.
> 6) Is java.util package finished ? I could not find Vector class there.
>
> Artur
>
Aaron got that last one pretty well.
--John Keiser
