kore 0.0.2

[tullmann at facility.cs.utah.edu]

> > I would agree that this is a solution, but it does seem a slightly clumsy
> > way of going about it. (But I don't think there is much choice here).
> 
> Well, the choice is to treat kore.system as a special case, and make
> it invisible to any class having a ClassLoader. I'm not familiar with
> Kaffe's internals, so I don't know how much work it would be.

This seems like a lot of effort to get around having to recompile
.class files when changes to the native interface are made. (I believe
that's the cost, at least.)  

As I see it, there are two sides to this.  First, the folks who would
like to work on the .java files, and second, those who might like to
change the native interfaces.  Now, I can't see much reason to go
around changing the native interfaces without changing the .java files
also.  These people shouldn't be too burdened by regenerating the .h
files.

So, that leaves the first case--folks just changing .java files.  Now,
looking through the Kore files so far, they have done a very good job
of reducing the number of native interfaces used (I count only 14
classes that have some direct reliance on the native interfaces.)  So,
its not all that many files anyway.  And the native interface
(i.e. the .h file) only has to be regenerated if the order or number
of member variables change.  (It would be ugly if you did forget to
regenerate the corresponding .h file.)  The native interface code has
to be recompiled *anyway* if you change any of the reference parameter
classes (classes, such as FileDescriptor, that are passed into a
native method.)  

The package environment used by Kaffe for native interfaces make this,
I think, even easier.  The makefiles can pretty much just "take care
of it."

I might be missing something, though.  I think the real big problem
with porting Kore to a new JVM will be generating the .h files for
things like java.lang.Object in the first place.  (javah will use
*its* native Object not Kore's Object.)

-Pat