kore 0.0.2

[Glynn Clements]

tullmann at facility.cs.utah.edu wrote:

> Okay.  Actually, after trying some things out with Kaffe, I think
> putting all the native methods in separate classes isn't worth the
> effort.  First, for the reason you note below that access needs to be
> restricted.  Second, kaffeh generates a "this" pointer even for static
> methods, which in the case of kaffe.system.Native* is rather useless,
> if the native method was a method on the actual object, then the
> "this" pointer would be quite useful.  Third, kaffeh needs to be run
> over lots of the java.*.* classes (for example NativeIO.read() takes a
> FileDescriptor object, so that class will need to be kaffeh'd anyway.
> The only reason I can see to group them is if several are actually
> shared between different objects.

The motivation for putting native methods in their own package was so
that people could modify the classes without having to recompile
anything.

I've generally tried to avoid use reference types as parameters
to native functions, preferring to extract the necessary primitive
members from the instance, and using non-native wrappers.

FileDescriptor is an exception as you *can't* legally get at the
underlying representation.

At present, the only reference types which are used by the native
functions are arrays plus the following:

String, Process, Object, Class, Thread, FileDescriptor,
Throwable, IOException, FileNotFoundException, SocketException.

> > The alternative is to make them non-public members of the
> > appropriate packages, which has the disadvantage that we have to
> > duplicate code for java.net.* and java.io.*.
> 
> Can't this be "fixed" by subclassing them from a common, private
> subclass?

Possibly. I'll think about that.
 
> I should let you know that I'm tainted, in that our research group has
> a source license for the JDK, and I've looked at SUN's src.zip.   So,
> I really shouldn't be contributing directly, but I can't see any legal
> problems with writing the Kaffe interface for Kore.

I don't know the details of the source license, but what remains to be
done is to generate C code which is largely dictated by the existing
implementations of Kore and Kaffe's JVM, neither of which should have
any relationship with Sun's classes.zip.
 
> Is there a Kore mailing list of any sort?  I'm not CC'ing Kaffe,
> because this really is about Kore and not Kaffe.

No, there isn't a Kore mailing list. I may get round to setting one up
if there's sufficient interest, I can find the time, and I can get the
server usage OK'd.

In any case, I'd have thought that changing Kaffe's native libraries
in order to use Kore for Kaffe was sufficiently on topic for the Kaffe
list, so for now I'm CC'ing correspondence to it.

> I think I'll be able to generate all of the stubs with a hideous hack.
> I'm going to rename the package from java.* to kore.*, so that loading
> the classes doesn't interfere with the loader (kaffeh) itself.  It
> might be worthwhile to leave the package name as kore.* for
> development (because we can fall back to the native Sun implementation
> underneath if necessary.)  Converting applications to run on kore
> vs. java would simply mean fixing all of the import statements at the
> top.  Any thoughts on this?

Er, well, Java programs tend to implicitly use java.lang, particularly 
String, StringBuffer, Boolean, Character, Integer, Long, Float,
Double, Object, Class, ClassLoader and the Throwable hierarchy.

I would imagine that there could be real problems trying to use both,
particularly in terms of the inheritance hierarchy vs. package
membership. Classes in kore.* would have to be subclasses of the
java.* classes, but would actually be in a different package, which
might cause problems.

-- 
Glynn Clements <glynn at sensei.co.uk>