harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [general] compatibility packages
Date Mon, 14 Aug 2006 00:07:53 GMT
On Sun, Aug 13, 2006 at 06:38:13PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Dalibor Topic wrote:
> > On Sat, Aug 12, 2006 at 02:27:29PM -0400, Geir Magnusson Jr wrote:
> >>
> >> Dalibor Topic wrote:
> >>> 'Harmony - runs 100% of apps Sun does (sure it's obviously a rubbish claim,

> >>> but you should trust us anyway on our other claims)' is not a very 
> >>> compelling tag line either.
> >> But this isn't what we're trying to say, so please don't put words in
> >> our mouth.
> >>
> >> The issue is removing speedbumps (no matter who put them there) on the
> >> road to users working with Harmony.
> >>
> >> People are busy, and don't generally have a lot of free time to tinker.
> >>    Time is a very valuable and scarce thing.  If someone chooses to
> >> *invest* some of their time trying out Harmony, lets make it as smooth
> >> as possible, and be as appreciative as possible.
> >>
> >> Sure, they may be doing the Wrong Thing by using software that makes the
> >> common mistake of using an internal Sun class, but that's really a
> >> secondary concern.
> > 
> > I believe you've largely misunderstood what I said, unfortunately. There
> > is no them vs. us here, and I am not trying to put words in mouths, or
> > playing wiesel wording and framing games. 
> 
> Ok - sorry.
> 

My apologies as well, for not being clear enough.

> > 
> > Look, I agree with pretty much with all you say, my point is that we 
> > can't compete with Sun on the ability to run 100% of code written for 
> > their VM, suncompat.jar or not. As Stefano said (he got the meaning 
> > of what I tried to get accross), that's not a game we can win. But 
> > we've got other qualities, as you've mentioned, and which matter to our 
> > users. Noone is using our VMs for their sun.* classes.
> 
> And we're not doing this to be able to compete with Sun on their
> implementation of sun.*.  We're doing it simply to make it easy for
> people to *try* Harmony *right now*.

I agree, I just don't think not having sun.* (on a case by case basis)
makes a negative difference. It doesn't stop people from trying our code right 
now easily. It only stops them from using functionality we haven't
implemented yet, but then the user experience is not going to be particularly 
different from them trying out other code where we haven't got an
implementation for. Given that we're all working on works in progress, a
few rough edges along the way should be expected by the kind tester, and
that our target audience is very intelligent and realizes that, I don't
see a particularly burning issue wrt to sun.* classes specifically.

See, what makes me very uncomfortable about it is the sort of
maintenance issues that Sun and IBM and whoever else needs to maintain
sun.* classes in their VMs, have to go through, as Jeroen described it:
backing out changes in order to keep broken code around since some
customer may need it. That's not a good thing. I'd rather carefully consider
if there is no better way to avoid such problems from the start on a 
case by case basis, than copying Sun's implementation's internals without 
weighing the merits and disadvantages of their designs. As Alex said,
it's a one way road that we can't go back from, once we start including
proprietary class library extensions, and have users relying on them.

> > 
> > The only interaction we've had with users so far on this issue has
> > shown that the user was able to spot a problem in his code, improve
> > it, and contributed useful feedback. The first two things would not have
> > happened if we had a suncompat.jar, and everyone seems to be better off
> > with the current outcome. Was it a speedump? Maybe. It helped the user,
> > though, and we should be as appreciative as possible about having such helpful
> > speedbumps, IMHO, that make people aware of potential migration issues
> > with their code, and make users come to us to give us their appreciatd 
> > feedback in the first place, rather than speeding through without a ...
> > (and here I lack a suitable driving analogy, but I hope you catch my 
> > drift anyway)
> 
> What if the problem was in Weblogic?  What if the user couldn't get it
> fixed?

I don't know. We could simply wait and see what happens when someone
tries to run Weblogic on our VMs. That hasn't happened so far, at least
not that I heard of it, so we could adopt the YAGNI approach for now.

I mean, if we are lucky, by the time our users start doing that, Weblogic 
may no longer be relevant for them, because they all switched to Geronimo, 
for example, right? ;)

cheers,
dalibor topic

> geir
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message