kore 0.0.2

[Glynn Clements]

tullmann at facility.cs.utah.edu wrote:

> 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.)  

Other way around. The purpose is to avoid having to recompile Kaffe
and it's libraries if the .java files are changed.

> 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.

But if you regenerate the .h files, you have to recompile
everything. That's what I was trying to avoid.

> 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.

Or their type.

> (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."

Assuming you have make, a C compiler, linker etc. This starts to
become an issue when Kaffe is sufficiently stable to start
distributing precompiled binaries. People who don't have a C compiler
but have javac (or guavac) might want to experiment with the java.*
classes.

> 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.)

Unless Kaffe's Object is Kore's Object. Right now it needs the one
from Sun's classes.zip.

Object is highly system-dependent. The only Java methods are
one-liners. Same goes for Class. Consequently I haven't put the native
methods for Object or Class in a separate class.

I could probably implement the native methods for java.{io,net,util}
without any knowledge of Kaffe. They're basically just interfaces to
the POSIX API. Threading might complicate matters if OS threads aren't
being used.

It's Object, Class, ClassLoader and Thread that are like to be the
real work.

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