Glynn Clements glynn at
Thu May 15 19:15:42 PDT 1997

Artur Biesiadowski wrote:

> What kind of replacement it is going to be ?
> Will it be just a rewrite of all classes in slightly different way (do not
> makes much sense to me ) or library with similar functionality but
> different classes/method names etc. ?
> I mean if it will be fully compatible with sun's classes ?
> If not what parts will be different (I think that at least java.lang.*
> should be the same) ?

Kore is intended to comply with the documented interface to the Java
class library, i.e. java.{lang,io,util,net,awt,applet}.

It has been developed purely from the published documentation
(i.e. the Addison-Wesley books), and is in no way based upon Sun's
implementation. In particular, it is designed to use the minimum
number of native methods, and is designed for maximum separation
between Java code and C code.

The main problem at the moment is that Kaffe's native methods are tied 
to Sun's implementation of the class library, i.e. the C structs
representing the classes are obtained by running kaffeh on the classes 
in Sun's file.

As a result, either:

1. Kaffe's native methods (and presumably some of its internals) will
have to be rewritten to use any alternative implementation, or

2. any alternative implementation must have classes which correspond
with Sun's implementation, in the sense of all classes having exactly
the same member variables as Sun's, in terms of name, type, order and

I'm not entirely sure how one could legally go about implementing
option (2), as the relevant information is not part of the published
specification, and presumably Sun's intellectual property.

Unfortunately I haven't seen any indication of a willingness to
implement option (1).

Regarding the current state of Kore, nearly all of the Java methods
have been written, although some are simply placeholders
(e.g. java.lang.Math uses simple approximations rather than the netlib
algorithms), and few classes remain unimplemented (FontMetrics,

None of the native methods have been written, and as Kaffe's native
methods cannot be used, none of the code has been tested.

Also there are no classes which are not specifically listed in the
specification, e.g. concrete subclasses of ContentHandler,
ProtocolHandler, Toolkit, etc.

Anyone interested in taking a look at the current state of play can
get it from (68 Kbytes).

Glynn Clements <glynn at>

More information about the kaffe mailing list