Re: file.encoding property

[Patrik Reali]

I think this makes sense (as long a java implementation is available).

I can see only one limitation at the moment: if someone wants to construct a
free J2ME (CLDC) API from Classpath.

The CLDC API contains only java.io; there, PrintStream writes to the
underlying stream according to the locale and VM configuration. There is no
explicit encoder (as far as I can see), but I guess it would rely on
something like the current encoders (maybe just hardcoded, because a generic
implementation it just too expensive on a small device).

-Patrik
--------
Patrik Reali
http://www.oberon.ethz.ch/jaos


> Brian Jones <address@hidden> wrote on Tue, 23 Sep 2003 07:17:07 -0400:
>
> >Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
> >looks like the nio versions could be used?
>
> It probably would make sense to switch to java.nio.charset.
>
> Some of us (Dalibor Topic; Mark Wielaard; Andy Walter; James Hunt; Ingo
> Proetel; Sascha Brawer) had discussed this during our meeting at LinuxTag
> in Germany.
>
> Quoting from Mark's meeting minutes (http://mail.gnu.org/archive/html/
> classpath/2003-07/msg00040.html):
>
> > The plan for character encodings is to move to the java.nio.charset
> > interface. We already have required encodings for this. But GNU
> > Classpath and gcj both still also have their old implementations
> > (which are actually used in most places). gcj also has a libiconv
> > provider (but not as java.nio.charset provider). A java.nio.charset
> > libiconv provider would be nice to have for those systems that
> > have that library.
>
> -- Sascha
>
> Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/
>
>
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath
>
>