At 10:51 AM 3/8/00 -0700, Patrick Tullmann <[EMAIL PROTECTED]> wrote:
>Todd L. Miller wrote:
>> When I get a chance, I'll try to look into the size of classpath
>> vs. Kore -- if Kore is compellingly smaller, I'll look into a switch.
>
>I don't know how big Classpath is but I know Kore is far smaller. :)
>However, Kore is only JDK1.0 compliant. I do recommend it as a
>stepping stone to more full featured class libraries at a later date,
>though---its good enough to run Javac on, for example. The other nice
>property of Kore is that there are few native methods and they are all
>grouped together in a nice, simple static-native-method-only
>package-private classes.
We must be brave and think of Kore as a stepping stone. It is most
efficient to support Java 0, and then Java 1, and then Java 2 -- in that
sequence. Think of it as the first step to bootstrap jJOS/decaf into
something you can fit into 8MB, with room left over for applications.
Kore design is similar to the Bytecode Native Interface (BCNI) and alt.*
package proposal. I like Kore and BCNI because they have few native
methods. These native methods are "concentrated" together in NativeLang,
NativeIO, NativeNet, etc. for Kore and LangBridge, IOBridge, NetBridge for
BCNI. Concentrating native methods into single classes is easier on a C/C++
programmer!
Unlike Kore, BCNI gives you the flexibility to create many implementations
of the bridge classes, in whatever package you want. While Kore puts its
Native.. classes in the java.* packages, BCNI lets you put your bridges in
your personal package. For example, a bridge for decaf should be in a decaf
package.
When Kore and BCNI are combined, wonderful things start happening. There
are many positive implications. Suddenly, your JVM-specific classes have
the freedom to be implemented in machine code *or* bytecode. That's the
ticket.
It is overwhelming to demonstrate this with Kaffe (Java 1) or classpath
(Java 2). I want to run JOS. I want to use JOS. I hope you do to.
>The .zip file is 214K uncompressed. There are about 160 files in
>Kore. It includes java.lang, java.net, and java.io. I have a local
>version that has a few fixes w.r.t. v0.0.7 (the last public version).
I am very pleased to find out that you have fixes to Kore. I have also been
"fixing" Kore. I'm sure many other people have fixed it, too. It is
unfortunate that we can't send fixes to Kore CVS. I have already contacted
one of the contributors to Kore. I asked if the JOS Project could use Kore
as a starting point. He said, "Yes".
I think we should work toward a distribution of Kore 0.1.0 and make it
available to the public. Why can't we put together a Kore Extension project
on SourceForge? I have code that's ready to upload, don't you?
>The homepage for Kore (embarassingly out of date) is
> http://www.cs.utah.edu/flux/java/kore/index.html
If we start a Kore Extension project on SourceForge -- for the purpose of
plugging it into decaf as a stepping stone, we should be able to contact
the author of the Kore homepage. That author should add a link to SourceForge.
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
