[Waba-spec] More on the Waba Core Classes

[Sean L. <se...@cs...>]

Guilherme wrote:

> > My opinion on this is: Waba is too different from the Java standard.
> > It's making porting difficult.  SuperWaba is pushing us even further in
> > this direction.  I think that if we're trying to establish a good
> > standard set of classes, we should bite the bullet and implement a good
> > set of basic classes rather than try to modify the noncompatible ones we
> > presently have.  We only have to do this once.
>
> In fact SW did not started that nightmare, i'm just continuing in the
> same path, exactly to make SW fully back compatible with Waba.

...well, I wouldn't exactly call it a nightmare!  But there are many
function calls in Waba and SuperWaba which are named differently than the
equivalents in Java.  This makes porting from Java unenjoyable.  Rick did
this, as I understand, to avoid the iron thumb of Sun, and that's
perfectly reasonable.  But Sun has been relatively tolerant of systems
which don't claim to be "Java" lately, except anything coming out of
Microsoft.  :-)

I think that, whenever it doesn't add significant burden to the VM, we
should strive to use classes and method names that make porting as simple
as possible.  But I'm not going hog-wild here.  I don't think that we
should implement MIDP etc.!  My goal here is to provide some similar
functionality in some core classes where we can, but be different where we
have to (like interfaces etc.)

> "Hi, I've been doing a skunkworks project on the feasibility of Java
> development on PDA platforms. So far in terms of getting a straight
> forward app up an running, SuperWaba wins in every way I care about.
>
> As far as I can tell, all the big commercial players are doing
> heavyweight "compliant" implementations of full JVMs on PDAs and/or
> MIDP with proprietary GUIs for PDA's. I'm interested in knowing if
> SuperWaba is on a different trajectory and if so, where it's headed?
>
> 1. Given infinite resources and a fair wind, what [might/will/should]
> SuperWaba be in a years time?
>
> 2. Is the intention to ultimately provide a complete cleanroom
> implementation of all concievable Java classes or to specifically
> avoid this in order to remain small and fast?"

My response to this person is as follows:

There is a tradeoff between compatibility with the Java codebase; and
good, fast portable design for PDAs.  Right now Waba has swung way out
towards good, fast portable design, ignoring compatibility.  SuperWaba has
swung out a little further still.  There were good justifications for this
at the time, but hindsight is 20/20.  In working with the Waba Core, I'm
trying to swing back *a*little*, to retain the design advantages of Waba
while providing a little more compatibility to make us not totally cut off
from the Java world.

Sean