Geir Magnusson Jr. wrote:
I assume that if the Harmony JVM gets half as good as is hoped
there will be companys who want to adopt the JVM but continue to
use Suns class library so that differences in libraries don't
hurt their customers.
If that is a goal of Harmony then we've just made things a lot harder.
So in summary: I just don't get it.
I suppose not - I thought the issue is really simple, and I'm sorry
it's gotten a bit off track.
We started with the idea that in part, we should look at modularization
of a VM platform. One of the connection points is the VM<->Class
library interface, and since we have something to start with - the GNU
Classpath interface - I suggested we start there, and see what
additional information we can gather from those that have done more
advanced and complete implementations (Sun, IBM, BEA, HP, etc) and with
those considerations, produce an interface that works for where we are
targeting to go.
No one is suggesting we standardize on Sun's interface, wait until the
JCP does something about this, or bundle our (or anyone else's) stuff
w/ Suns libraries. (As for the latter, it would be nice if it was an
option for those that choose to go that route... Freedom is good :)
Learning from Sun et.al. and taking the best ideas is all good...
My reaction was to the notion that a goal of Harmony should be to
be API-compatible with Sun. Reading the first blurb quoted above,
that seemed to be the suggestion (maybe I misread it). IMHO it's
inappropriate to spend any (more) time worrying about API compatibility
right now, when the possibility is so far off.
On the other hand, anyone who has any bright ideas for how the class/JVM
API that Classpath has now might be improved please speak up (preferably
on the Classpath mailing list, not this one?)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
