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 Sat, 12 Aug 2006 12:42:55 GMT
On Fri, Aug 11, 2006 at 03:11:48PM +0100, Tim Ellison 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.
> 
> If you want to duplicate the char conversion data then sure, but taking
> a multi-MB hit isn't palatable to many apps when sun.io is sitting there
> smiling at them.
> 

java.nio.charset.CharsetEncoder is right there, a standard API, and does
not add a multi-MB hit. ICU does, but when the choice is between
maintainable applications or software slapped together in hope that it
works, it's clear to me what to chose.

> I saw a few uses when testing apps, but maybe I was unlucky. For
> example, Xalan was using it until it was pointed it out last year
> (http://issues.apache.org/jira/browse/XALANJ-2087).

It kind of proves the point that there is no good reason to use sun.io
classes today.

> > 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.
> > 
> > That holds in general for any code using implementation-specific 
> > interfaces.
> 
> Exactly.
> 
> >> 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.
> 
> Ack -- I see it here (just so others can find it too).
> http://developer.classpath.org/mediation/ClasspathMigration
> 
> > 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.
> 
> It's pragmatic because as I said, sometimes it is beyond the immediate
> control of the application, and sometimes you won't get a second chance
> to demonstrate your wares.

So if I can't run the sun.misc.Unsafe remote exploit on Harmony it is a
failure? ;)

> 'Harmony - runs fewer apps than the leading brand' is hardly a
> compelling tag line.

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

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.

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.

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

> > 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.
> 
> I agree, of course.
> 
> >>> 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.
> 
> Where people who can fix it are made aware and choose not to then I
> agree, shame on them.
> 
> Regards,
> Tim
> 
> -- 
> 
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
> 
> 
> ---------------------------------------------------------------------
> 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