Artur Biesiadowski wrote:
> Here are few questions for you:
I'm not the expert in most of these areas, but I'll answer as best I can and
let others correct me.
> 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 ?
Our approach is to write as little native code as possible. This was based
on JNI performance problems with the JDK, which it now looks like we won't
be able to support anyway. (Plus Java code is less of a pain to write than
JNI). I am not sure that the native support for java.lang has been written
because the design of our VM interface is not complete and that is what most
of the java.lang native code deals with.
> 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 ?
John, Chris, and Paul have been debating this. A final design has not yet
been selected. I believe that we have been leaning towards creating a
gnu.java.vm class containing methods that should be called by Classpath to
supplement what is available via JNI. John seems to want to make things as
VM independent as possible and migrate as much functionality as possible
into Classpath. I've mostly been of the opinion that we should have as
little as possible in Classpath and hook into JVM's on a mostly case by case
basis. (There aren't very many we need to support).
This topic gets a lot of discussion but it is important to remember that the
vast bulk of the class library is totally VM independent. I've written
java.net and java.io and found only one VM dependent method to date
(java.io.File.deleteOnExit()).
> 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.
That depends on the level of granularity you wanted to provide. Replacing
parts of java.io with pure native routines (for example) would probably
require that you replace the entire class where you want to add new native
routines, since Java doesn't support conditional compilation to make
additional methods native depending on the target VM. (We may include some
cpp type #ifdef's for just this purpose, though).
> 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)
>
> 5) What are these class signers, BTW ?
You are one of the Chives developers, I take it? It looks like Chives is
under an X11 style license, so is free software. Thus it would be one of
the JVM's that we would be interested in supporting. I'm not sure what
you're requirements are, but there are probably going to be only a very
limited number of free JVM's. We can probably tailor what we do to meet
your needs somewhat. Japhar is our first target, but if there are things we
can do now to support other free JVM's that will prevent big problems later,
then that is a good thing.
I think John Keiser wrote java.lang.Class, so he can address your questions
here.
> 6) Is java.util package finished ? I could not find Vector class there.
java.util is not finished. Stuart Ballard wrote some of it (which is
probably in CVS). Greg Smith wrote some of it (which is sitting on my hard
drive). Also, we hear that SableCC or something has a java.util
implementation already done. Paul was supposed to contact them to see if we
could use it rather than rewriting it, which is why the status of that
package is kind of a mess right now. Paul?
--
*****************************************************
* Aaron M. Renn *
* Email: [EMAIL PROTECTED] *
* Homepage: <URL:http://www.urbanophile.com/arenn/> *
*****************************************************
