harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [general] compatibility packages
Date Mon, 14 Aug 2006 01:24:31 GMT

Dalibor Topic wrote:
> 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
>>>>> 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.


I don't agree that weaning people off is impossible.   And even if it
is, right now we're talking about one base 64 encoding class....

>>> 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.

You're missing the point.  I don't want to play fetch me a rock here -
for all the Martin's of the world that send us a mail, look into the
problem, decide to take action, etc. there are probably at least 100 who
just say "eh. it's broken. figures.  open source crap..." and move on.

Right now, we need to engage those 100 people.  Even if we never can
stop supporting that base64 encoder class, I don't think it's a high
price to pay.  After all, we know Sun isn't going to change it :)

> 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? ;)

I hope we've got a pretty strong story mid next year, and I'm fairly
sure that BEA will still be around :)


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

View raw message