From: Tom Tromey <[EMAIL PROTECTED]>
Date: 14 Nov 2005 10:41:57 -0700
> > "Ito" == Ito Kazumitsu <[EMAIL PROTECTED]> writes:
>
> Ito> I think an invalid value of file.encoding should be treated as if
> Ito> it were "ISO-8859-1". Such is the behaviour of Sun's JDK.
>
> Perhaps we should check
From: Ito Kazumitsu <[EMAIL PROTECTED]>
Date: Tue, 15 Nov 2005 00:57:35 +0900 (JST)
> I think an invalid value of file.encoding should be treated as if it
> were "ISO-8859-1". Such is the behaviour of Sun's JDK.
A further study shows that an invalid value of file.encoding being
treated as if it w
From: Ito Kazumitsu <[EMAIL PROTECTED]>
Date: Tue, 15 Nov 2005 00:57:35 +0900 (JST)
> I think an invalid value of file.encoding should be treated as if it
> were "ISO-8859-1". Such is the behaviour of Sun's JDK.
I expected this fix would resolve the bug #22948 (Infinite recursion
in java.nio.char
> "Ito" == Ito Kazumitsu <[EMAIL PROTECTED]> writes:
Ito> I think an invalid value of file.encoding should be treated as if
Ito> it were "ISO-8859-1". Such is the behaviour of Sun's JDK.
Perhaps we should check this once at startup, instead of every time in
PrintStream? I'm thinking that we
Hi,
I think an invalid value of file.encoding should be treated as if it
were "ISO-8859-1". Such is the behaviour of Sun's JDK.
I added a new mauve test gnu/testlet/java/io/PrintStream/encodings.java.
2005-11-14 Ito Kazumitsu <[EMAIL PROTECTED]
* java/io/PrintStream.java(PrintStream
