From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Fri Jan 29 1999 - 14:46:14 EST
On Jan 29, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>> The main reason is that the goal of the kaffe project is to create
>> a free clone for Java, and not for extensions of Java. At this point,
>> we have enough trouble getting Java right, as you can witness yourself.
And max@immsp.kiev.ua (Maxim Kizub) replied:
> I do not see how this may affect pure java. All additions are
> #ifdef-ed, there will be no change in kaffe, if that EXTENDED_VM
> macro is not defined.
They may get other developers confused about what that piece of code
is doing there, and whether they should try to put time into modifying
them in case they notice some other change happens to break them.
Although my changes to Kaffe in order to support Guaranį are very
localized, and quite simple ones, all of them only enabled via #ifdef
GUARANA, I wouldn't dare putting them into the Kaffe CVS tree, giving
the other developers of Kaffe any kind of feeling that they're
responsible for supporting my modifications too. A separate branch,
maintained primarily by myself, might be reasonable if Tim and Peter
would agree to provide anonymous CVS services for my project, but I
wouldn't ask them to do it because I have benefitted from their work
much more than I could ever contribute back. So I keep my own
modified CVS tree of Kaffe, and release Guaranį whenever I feel like
doing it.
> New bytecodes are not kiev-specific at all. They are simply
> generalized support for effective closures and method references
> implementations. There is nothing specific with this instructions.
That's not Java, so it has nothing to do with Kaffe. Computational
Reflection with meta-objects and transparent interception of
operations (namely, Guaranį :-) is not Java, so it doesn't fit in
Kaffe.
> Any, any other language that compiles with JVM bytecode target
> can use them, they sutable for procedural languages like
> kiev or pizza, as well as for any other langauge that supports
> closures - SmallTalk, scheme, etc.
Great, there may be lots of people interested in your project, so just
release it, either as a full distribution or as a patch for particular
snapshots or releases of Kaffe, like I do for Guaranį.
> But about "we also" - didn't I asked about these changes before?
> There were no discussions in kaffe core team when I asked first
> time? IMHO, it whould be more polite to say me about
> rejecting these changes before I started to do them :-|
They're not being rejected (there's no such thing in the Free Software
world). It just doesn't fit in a pure JVM, so we're suggesting that
you should maintain your package separately, so you wouldn't depend on
us for your updates, bug-fixes and releases. In Eric S. Raymond's
words,
> This changes ARE NOT KIEV SPECIFIC. Period.
They divert us from the only purpose of Kaffe, that is being a GPLed
JVM compliant with Sun's specifications.
> But splitting a project is really the problem. It's the last thing I
> wish to do.
Don't think of it as splitting, think of it as maintaining extensions.
Believe me, it will be better for you to be able to update your own
CVS tree whenever you want.
> One possible answer is that Sun Inc. is the best
> firm on the earth. Really?
Certainly not. That's why we're trying to beat them :-)
But there's a very important point in not to diverting from Sun's JVM
Specification: to turn the WORA myth into reality.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:53 EDT