kore 0.0.2

[Glynn Clements]

Gary Howland wrote:

> > The motivation for putting native methods in their own package was so
> > that people could modify the classes without having to recompile
> > anything.
> 
> Isn't this already possible?  Since javah only looks at the native 
> declarations, there should be no reason that the rest of the class can't
> change, as long as the native declarations stay the same.  Or am I
> missing something here?

If the set of member variables of a class changes, the C struct which
represents that class changes, which means that any native methods
which access elements of that struct will have to be recompiled.

> > > Can't this be "fixed" by subclassing them from a common, private
> > > subclass?
> > 
> > Possibly. I'll think about that.

Now I have thought about it, the superclass would have to be public if it's
to be referenced from both java.net and java.io.

I was originally planning to put NativeIO in java.io, etc., but it
would have to be public so that java.net can reference it.
 
> 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.

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