harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: BASE64Encoder class missing?
Date Thu, 10 Aug 2006 09:00:37 GMT
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

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.

Thanks,
Mikhail

2006/8/10, Tim Ellison <t.p.ellison@gmail.com>:
> I'll create a suncompat component and see where we go from there...
>
> Tim
>
> Alex Blewitt wrote:
> > On 10/08/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> >> Anthony Green wrote:
> >> > On Wed, 2006-08-09 at 17:58 -0400, Geir Magnusson Jr wrote:
> >> >> Yes- the idea is to provide that "suncompat.jar" for that reason with
> >> >> those clases in the sun.* namespace that user apps depend on.
> >> >
> >> > This way lies madness.  I urge you to take a strong stand against bad
> >> > applications.
> >>
> >> Oh, don't get me wrong - we really want to.  But we want adoption of the
> >> harmony codebase as well.  We think that we have a reasonable balance -
> >> provide the functionality in an separable, modular way at first to make
> >> it easy for people to try and adopt harmony.
> >
> > May I suggest that we try and:
> >
> > 1) Make available a suncompat.jar, which re-writes calls to o.a.h or
> > similar (or subclasses them ...)
> > 2) Explicitly don't make it part of the default classpath ala
> > 'tools.jar' in the standard Sun implementation when running HarmonyVM
> > code
> > 3) Put up a FAQ saying that 'If you depend on e.g. sun.*, stick the
> > suncompat in the classpath'
> >
> > That way, out-of-the-box we don't have it, but there's an easy fix for
> > people who trip up over it. However, if people just need to get it
> > running, then they have a trivial workaround that doesn't involve
> > changing their code.
> >
> > The same could also be provided for code that depends on sun.JavaC or
> > whatever ...
> >
> > Alex.
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> --
>
> 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