Re: file.encoding property
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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
>
>
>
>
> ___
> Classpath mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/classpath
>
>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
David> The EncodingManager expects the system property file.encoding
David> to be set but I couldn't find any indication of who was
David> responsible for setting this property, when and where.
I think the VM must set it during startup. That's what libgcj does.
Brian> gnu/java/io/EncodingManager uses System.getProperty("file.encoding",
Brian> "8859_1");
Brian> java/net/URLEncoder.java uses System.getProperty("file.encoding",
Brian> "8859_1");
Brian> java/util/logging/XMLFormatter.java uses
Brian> System.getProperty("file.encoding") and later defaults to "UTF-8" if
Brian> null
I wonder if the default setting should be in gnu.classpath.Configuration.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Sascha Brawer wrote:
Brian Jones <[EMAIL PROTECTED]> 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.
So I guess the first step would be to take the libiconv provider and
make it work in the nio framework, and then to convert the rest to it as
well, before switching, as it would make the switch most painless for
the libgcj guys, I guess. For kaffe, switching to Classpath's style
charsets also depends on the availability of libiconv based conververters.
cheers,
dalibor topic
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Brian Jones <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Sascha Brawer <[EMAIL PROTECTED]> writes:
> Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 00:28:16 -0400:
>
> >A grep through the source confirms many complaints about Sun not
> >[...] providing a standard means of getting at the
> >available encodings.
>
> They have added this with 1.4. See
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html
Is there a reason to keep gnu.java.io.{encode,decode}.* around when it
looks like the nio versions could be used?
Brian
--
Brian Jones <[EMAIL PROTECTED]>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 23 Sep 2003 00:28:16 -0400: >A grep through the source confirms many complaints about Sun not >[...] providing a standard means of getting at the >available encodings. They have added this with 1.4. See http://java.sun.com/j2se/1.4.2/docs/api/java/nio/charset/Charset.html -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: file.encoding property
Brian Jones wrote: > A grep through the source confirms many complaints about Sun not > documenting this or providing a standard means of getting at the > available encodings. ;) I think a JVM is supposed to > provide this if they want. I looked at the hacking guide and various other bits but didn't quite see how a VM is expected to set this file.encoding value. I guess if you never set it and your platform encoding is UTF-8 then things will just magically work. > More confusingly we provide > DecoderUTF8 and EncoderUTF8 which implies the EncodingManager would > load on "UTF8" rather than "UTF-8". There's an alias to deal with this situation. Thank. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: file.encoding property
David Holmes <[EMAIL PROTECTED]> writes:
> Hi everyone,
>
> The EncodingManager expects the system property file.encoding to be
> set but I couldn't find any indication of who was responsible for
> setting this property, when and where. Is this something that would
> just be set from the command-line? Or should it be determined by
> native code somewhere in the VM startup process?
A grep through the source confirms many complaints about Sun not
documenting this or providing a standard means of getting at the
available encodings. ;) I think a JVM is supposed to provide this if
they want. If you do nothing it should still work, but you can
override the default if you want including using file.encoding.pkg to
prepend to the default of gnu.java.io for where we attempt to find
encoders/decoders.
gnu/java/io/EncodingManager uses System.getProperty("file.encoding",
"8859_1");
java/net/URLEncoder.java uses System.getProperty("file.encoding",
"8859_1");
java/util/logging/XMLFormatter.java uses
System.getProperty("file.encoding") and later defaults to "UTF-8" if
null, which seems to be an error either here or in the documentation
in java/io/InputStreamReader.java. More confusingly we provide
DecoderUTF8 and EncoderUTF8 which implies the EncodingManager would
load on "UTF8" rather than "UTF-8".
There is a hacking guide reference in Chapter 11. I can't connect to
gnu.org currently so I can't link it.
Brian
--
Brian Jones <[EMAIL PROTECTED]>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
file.encoding property
Hi everyone, The EncodingManager expects the system property file.encoding to be set but I couldn't find any indication of who was responsible for setting this property, when and where. Is this something that would just be set from the command-line? Or should it be determined by native code somewhere in the VM startup process? Thanks. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
