archie at whistle.com
Wed May 14 17:27:23 PDT 1997
> Note: I agree Kaffe should support JNI. However, it should also support
> a faster API. The two goals do not necessraily conflict. I just am
> not convinced that JNI is a terribly high priority for Kaffe.
> I think it would be nice to have a "Kaffe Native Interface". This would be
> a set of macros that could be compiled into *either* JNI or a
> faster interface, using conditional compilation. I don't know how
> difficult or kludgy it would be to come up with something like that.
This is a bit off the topic, but here goes...
Both Kaffe and Toba (http://www.cs.arizona.edu/sumatra/toba) are very
cool freeware products for executing Java (Toba is not as freeware as
Kaffe right now, but hopefully will be soon if the authors get their
way). Kaffe is a JIT compiler, whereas Toba is a Java -> C translator.
In a perfect dream world, Kaffe and Toba would just be two completely
interoperable aspects of the same thing.
That is, the binary interface (eg., "C" or JIT calling conventions)
would be the same. So, you could...
- Compile your favorite often-used Java package into a single
shared library using Toba
- Run Kaffe to execute some Java bytecode, which then invokes
objects from the compiled package via the shared library
In other words, once compiled into machine code, Kaffe wouldn't know
the difference between a class that was compiled ahead of time (a la
Toba) and one that was compiled "just in time" (a la Kaffe).
You could even have a hybrid someday, where JIT compilation could
optionally compile C code using gcc instead of directly to machine code,
as Kaffe does now.
This would require defining this custom interface (one that would be
much more efficient than JNI) so both products could adhere to it.
Has any thought been given to this kind of thing? Has there been much
contact between the two "camps"? What are my implicit but wrong
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
More information about the kaffe