kore 0.0.2

[Artur Biesiadowski]

On Wed, 21 May 1997, Glynn Clements wrote:

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

I don't think that there is big problem with using them both at the same
time. As long as kore would implement all public/protected fields and
methods given in specs we can use kore.zip in classpath before classes.zip
- it will cause kaffe to use classes from kore, if it is not found there
go to classes.zip. There is no penalty for duplicating class entries in
diffrent CLASSPATH regions - just the first would be used.

For example we could hack out classes needing native support from kore for
now, test the rest, and if it is working we could add single classes
without big problem.

Artur