Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 64.74.244.70 is neither permitted nor
 denied by domain of geir@pobox.com)
Message-ID: <44DC7E5E.9010706@pobox.com>
Date: Fri, 11 Aug 2006 08:55:58 -0400
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [general] compatibility packages
References: <1155162283.2717.39.camel@localhost.localdomain>
 <44DA8C59.3080805@pobox.com>
 <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>
 <44DB585C.4070009@pobox.com> <20060810232103.GA30077@pogo.kaffe.org>
In-Reply-To: <20060810232103.GA30077@pogo.kaffe.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Dalibor Topic wrote:
> On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote:
>>
>> Dalibor Topic wrote:
>>>
>>> Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks
>>> to the JVM JSR not being ahead thinking enough to specify an API for low-level 
>>> operations. It may or may not work depedending on how a VM interprets
>>> the non-existent spec for that class, so it is practically useless,
>>> unless it is running on the VM it was written on, i.e. Sun's. It may or
>>> may not work by chance, rather than by virtue.
>> I think you are being too harsh here, but that notwithstanding, one of
>> the things we can do as open implementations is petition the EG to
>> actually define these in the spec once we show that there's a good
>> reason to do so, namely the independent implementations.
> 
> The independant implementations are not using sun.misc.Unsafe. Why would
> anyone want to use an undocumented implementation-specific class from
> another implementation in their own? That makes no sense. There is no
> point in petitioning the EC to specify sun.misc.Unsafe since no one in
> their right mind uses it, except Sun, in the interna of their
> implementation. That's like asking the EC to specify org.kaffe.util.Ptr,
> or something equivalently pointless from DLRVM.

It makes sense if you wish to use Doug's concurrency package as-is, as
it has dependencies on sun.misc.Unsafe, which I think is a Good Thing.

After we do that, I think we then go back to the EG and point out that
in order for the world to reuse this code, we need to have
sun.misc.Unsafe defined (of course, it would be given another namespace...).

> 
> What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, 
> with a sane API that does not require computing field offsets manually, 
> like sun.misc.Unsafe seems to do. ;)

That would a good thing to ask for two - the two would make a nice request.

> 
> The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather
> simple bug in Doug Lea's java.util.concurrent implementation: using 
> Sun-specific classes directly, rather than delegating to some 
> java.util.concurrent.VMCompareAndSwap interface layer. That means anyone 
> adopting the code needs to repeat the mistakes of Sun's implementation 
> (which has, coincidentally, had a very straightforward remote execution 
> exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. 
> 
> Yay. :/
> 
> Other than Doug's code, sun.misc.Unsafe does not matter at all, unless
> you want "remote-execution-exploit-for-remote-execution-exploit"
> compatibility. I believe that's too much to ask for. ;)

I think we've been clear all along why we'd implement this - we want to
use Doug's code.

[SNIP]

>> Sure, but again, not everyone will be as wise as Martin - they'll just
>> bail on us.  They may even realize that there's a problem with their
>> code, but there may be nothing they can do about it.
> 
> People bailing on us is not a problem, as people *stuck with Sun-specific code* will
> (and should, IMHO) only use Sun's VM anyway. People blindly trusting us because
> we pretend to run some Sun-specific code according to some unspecified interface 
> is a problem, both for them, as their code will obviously behave differently from
> what it expects, in subtle ways, if they are very unlucky, and for us, as we have 
> to chase unreproducible behaviour as Sun changes their internal
> interfaces around. See the sad story of Ant's chasing around of
> sun.tools.javac.Main tail over and over again.

Oh, come on.  You talk like the rest of the spec is rock solid and
perfectly defined.  We're spelunking the RI through black-box testing
all the time in our drive to get full behavioral compatibility.  Adding
a few utility classes that people are unfortunately using - knowingly or
unknowingly - is simply good customer service, IMO.

> 
> The 'works 100% like Sun's VM out-of-the-box for Sun-specific code' niche is 
> already taken by Sun. There is no point in trying to compete with them on that, 
> or for the audience that wants and expects that. Been there, done that,
> etc. ;)

I think we'll have to continue to disagree on this one.  I do want
Harmony to work 100% like Sun to start because we want users to be able
to effortlessly transition to Harmony.  Software is nothing without users.

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