Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

Dalibor Topic wrote:
> On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
>> Dalibor Topic wrote:
>>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
>>>> Mikhail Loenko wrote:
>>>>> The problem is Base64 functionality is unavailable through the
>>>>> standard API, so people have a choice either use unportable sun.*,
>>>>> o.a.h.*, etc or create the coder from scratch
>>>> Understood, I think people are 'driven' to using the non-API types
>>>> though necessity rather than doing so by mistake.
>>> Hardly. Many replacements for Base64 exists, for example GNU Classpath
>>> recommends using Apache Commons Codec for projects compatible with the
>>> Apache license.
>>>
>>> Amateur developers use non-standard classes because they are too lazy 
>>> to think for themselves, and accordingly copy broken code around projects. 
>>> Alas, a language designed to appeal to the masses naturally attracts a 
>>> lot of people who'd have trouble producing portable code in any programming 
>>> language. :)
>> I was being charitable.  For sure many such usages can be easily
>> avoided, but in other cases no so easily; like CharToByteConverter would
>> require duplicating a wad of data, and I don't know of any third-party
>> impl. of Unsafe.
> 
> Is there something that CharToByteConverter does that
> CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
> code using CharToByteConverter in years.
> 
> 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.

> 
> That holds in general for any code using implementation-specific 
> interfaces.
> 
>> We should appeal to app developers to change implementation dependent
>> code (even provide a recipe book of recommended solutions), but be
>> pragmatic about the need to run the current version.  In many cases it
>> may be beyond the apps immediate sphere of influence (i.e. dependent
>> libraries).  If everyone responded as quickly and effectively as Martin
>> we would have no worries.
> 
> We've been doing that for years. See the GNU Classpath migration page in
> the Wiki that describes how to fix such broken code in many cases. Being
> 'pragmatic' solves nothing, it just encourages people to continue behaving
> in dumb ways, because their code still may run, somehow, even if there
> is no way for Harmony to ensure that it will behave as they expect from
> whatever buggy Sun JDK they are using to run it usually in the corner
> cases, because there is no spec, and there are no tests.
> 
> Awarding incompetence doesn't solve the problem. That being said, kudos
> to Martin for fixing the bug in his code. Had we had a Base64 class,
> that bug wouldn't have showed up, and his code would have failed
> elsewhere, or behaved differently on another VM. With the fix, his code
> is portable, behaves in the same way on any VM, and may even be faster
> than a vm-specific 'just for compatibility' implementation.
> 
> There is no downside to simply fixing the buggy code.

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.

> 
>>> On a side note, I seem to recall reading on Sun's javac engineer's blog
>>> that javac won't allow access to sun internal classes sooner or later,
>>> so idiot-proofing class libraries may not be very useful, anyway,
>>> as people will have to rewrite such code, or preferrably, throw it away.
>> It will be interesting to see what havoc is unleashed by attempts to
>> reduce the visibility of sun internal packages by the compiler and at
>> runtime.
> 
> I assume it will just cause unmaintained libraries to be substituted by
> maintained ones, as people trade up to higher quality implementations of
> functionality they need. Code that uses sun.* classes is a bad smell, to
> invoke Fowler. If it doesn't get fixed, just get rid of it, and use
> something else that doesn't stink.

Yah, but I think it's insane to enforce restrictions on one company's
package namespace in the compiler.  This should be a general feature :)

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

Re: [general] compatibility packages

[Geir Magnusson Jr <ge...@pobox.com>]

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

Re: [general] compatibility packages

[Dalibor Topic <ro...@kaffe.org>]

On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote:
> 
> 
> Dalibor Topic wrote:
> > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote:
> >> Dalibor Topic wrote:
> >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote:
> >>>> Mikhail Loenko wrote:
> >>>>> The problem is Base64 functionality is unavailable through the
> >>>>> standard API, so people have a choice either use unportable sun.*,
> >>>>> o.a.h.*, etc or create the coder from scratch
> >>>> Understood, I think people are 'driven' to using the non-API types
> >>>> though necessity rather than doing so by mistake.
> >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath
> >>> recommends using Apache Commons Codec for projects compatible with the
> >>> Apache license.
> >>>
> >>> Amateur developers use non-standard classes because they are too lazy 
> >>> to think for themselves, and accordingly copy broken code around projects. 
> >>> Alas, a language designed to appeal to the masses naturally attracts a 
> >>> lot of people who'd have trouble producing portable code in any programming 
> >>> language. :)
> >> I was being charitable.  For sure many such usages can be easily
> >> avoided, but in other cases no so easily; like CharToByteConverter would
> >> require duplicating a wad of data, and I don't know of any third-party
> >> impl. of Unsafe.
> > 
> > Is there something that CharToByteConverter does that
> > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen
> > code using CharToByteConverter in years.
> > 
> > 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.

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

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

> 
> > 
> > That holds in general for any code using implementation-specific 
> > interfaces.
> > 
> >> We should appeal to app developers to change implementation dependent
> >> code (even provide a recipe book of recommended solutions), but be
> >> pragmatic about the need to run the current version.  In many cases it
> >> may be beyond the apps immediate sphere of influence (i.e. dependent
> >> libraries).  If everyone responded as quickly and effectively as Martin
> >> we would have no worries.
> > 
> > We've been doing that for years. See the GNU Classpath migration page in
> > the Wiki that describes how to fix such broken code in many cases. Being
> > 'pragmatic' solves nothing, it just encourages people to continue behaving
> > in dumb ways, because their code still may run, somehow, even if there
> > is no way for Harmony to ensure that it will behave as they expect from
> > whatever buggy Sun JDK they are using to run it usually in the corner
> > cases, because there is no spec, and there are no tests.
> > 
> > Awarding incompetence doesn't solve the problem. That being said, kudos
> > to Martin for fixing the bug in his code. Had we had a Base64 class,
> > that bug wouldn't have showed up, and his code would have failed
> > elsewhere, or behaved differently on another VM. With the fix, his code
> > is portable, behaves in the same way on any VM, and may even be faster
> > than a vm-specific 'just for compatibility' implementation.
> > 
> > There is no downside to simply fixing the buggy code.
> 
> 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.

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

> > 
> >>> On a side note, I seem to recall reading on Sun's javac engineer's blog
> >>> that javac won't allow access to sun internal classes sooner or later,
> >>> so idiot-proofing class libraries may not be very useful, anyway,
> >>> as people will have to rewrite such code, or preferrably, throw it away.
> >> It will be interesting to see what havoc is unleashed by attempts to
> >> reduce the visibility of sun internal packages by the compiler and at
> >> runtime.
> > 
> > I assume it will just cause unmaintained libraries to be substituted by
> > maintained ones, as people trade up to higher quality implementations of
> > functionality they need. Code that uses sun.* classes is a bad smell, to
> > invoke Fowler. If it doesn't get fixed, just get rid of it, and use
> > something else that doesn't stink.
> 
> Yah, but I think it's insane to enforce restrictions on one company's
> package namespace in the compiler.  This should be a general feature :)

Go ahead and start a JSR ...  I'd propose com.microsoft for a start. ;)

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