Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sat, 12 Aug 2006 18:30:51 -0700
To: harmony-dev@incubator.apache.org, geir@pobox.com
Subject: Re: [general] compatibility packages
Message-ID: <20060813013049.GB16820@pogo.kaffe.org>
References: <636fd28e0608100120s701d9be4pfd964e890da4b22@mail.gmail.com>
 <44DAF35B.20000@gmail.com>
 <906dd82e0608100200r28561a33ga2ae65ee5786b87@mail.gmail.com>
 <44DAFC0E.9080600@gmail.com> <20060810115719.GA32121@pogo.kaffe.org>
 <44DB2816.3040309@gmail.com> <20060810133840.GA7714@pogo.kaffe.org>
 <44DC9024.8050305@gmail.com> <20060812124255.GA23610@pogo.kaffe.org>
 <44DE1D91.8040604@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44DE1D91.8040604@pobox.com>
User-Agent: Mutt/1.3.28i
From: Dalibor Topic <robilad@kaffe.org>

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. 

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.

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)

cheers,
dalibor topic

> 
> > 
> > The 100% like Sun tag line has shown time over time to be false for IBM's 
> > VM for example, since IBM does not ship some of the classes Sun does, so 
> > vm-specific code using them fails in funny ways on it.
> > 
> > But that's how it is, 100% maching semantics is practially only possible by 
> > using the exact same sources. And we're deliberately not doing that, and 
> > making our own decisions on quirks of the spec.
> 
> And we're making decisions to behave like the RI.
> 
> Our goal - yours and ours - is to get people onto open source and
> free-as-in-Stallman implementations of Java.
> 
> Given that we're trying to be an alternative to proprietary
> implementations that are a) free-as-in-beer and b) technically excellent
> and that licensing is mostly irrelevant to a vast number of users,
> taking down the roadblocks is prudent.  We need to make the switching
> cost as low as possible.
> 
> > 
> > Harmony is *always* going to run fewer apps than the leading brand,
> > unless it uses the exact same set of sources, no matter what sort of
> > outlandish marketing claims we chose to use as tag lines.
> 
> We never chose any of those marketing claims.  You did.  Our goals are
> compatibility with the spec, high quality, portability, modularity and
> transparent, open community.  One of the tactics to achieve that is to
> hold our nose and implement necessary sun.* to help users switch.
> 
> At the same time, we can call attention to the problem, and we actually
> have a very good story for people - "bring apps over using our sun
> compatibility library, and assuming we do something like have it
> optionally log usages etc, and then let those logging/whatever features
> help you find and remove these problems..."
> 
> > 
> >> I believe that everyone wants to reduce dependencies on the non-API
> >> types.  It is a millstone for IBM and Sun and BEA etc if they cannot
> >> modify their implementations without customers coming down on them.  But
> >> at this point we cannot call the shots from Harmony.
> > 
> > We can't call the shots on IBM's, Sun's and BEA's implementation anyway,
> > unless they switch to Harmony ;) What we can do is to help people improve
> > their application code by helping them notice that they are using buggy,
> > implementation-dependant software.
> 
> Right.  And the only way they are going to do that is if they use
> Harmony, so we can tell them.  And they aren't going to use Harmony - at
> least right now - if we're in their face telling them that they are
> wrong, and therefore we won't let their programs run.
> 
> 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