harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: BASE64Encoder class missing?
Date Thu, 10 Aug 2006 11:57:19 GMT
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. :)

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.

cheers,
dalibor topic

> 
> > Alternative to suncompat is separating all similar functionality into
> > a separate redistributable module that would be runnable on RI, so
> > that people could use it in their apps.
> 
> If we could get people to change their apps then I would agree.  In fact
> I would expect that most of the non-API functionality in common usage is
> already available elsewhere there if apps wanted to change (well, maybe
> not Unsafe, but...).
> 
> But we are trying to fix it on the Harmony side.
> 
> I'll go ahead an put in the suncompat module, but don't let that be the
> end of the debate -- it is trivial to add it and I have no qualms about
> removing it later if that's what we choose to do.
> 
> 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