harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [general] compatibility packages (was: Re: BASE64Encoder class missing?)
Date Thu, 10 Aug 2006 12:35:34 GMT
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.

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.

> 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



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

View raw message