[Waba-spec] More on the Waba Core Classes
Status: Abandoned
Brought to you by:
bornet
From: Sean L. <se...@cs...> - 2001-10-09 19:33:23
|
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 |