[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug Report
From: |
Mark Wielaard |
Subject: |
Re: Bug Report |
Date: |
Fri, 16 Nov 2001 17:10:49 +0100 |
User-agent: |
Mutt/1.3.23i |
Hi,
On Tue, Nov 13, 2001 at 02:30:51PM +0100, address@hidden wrote:
> Bug Report:
> -----------
> Properties.load opens an InputStreamReader with
> decoder "ISO-8859-1".
>
> In java.io.EncodingManager the decoder is mapped to the
> class gnu.java.io.DecoderISO-8859-1, which doesn't exists.
> The close and obvious match is gnu.java.io.Decoder8859_1
This comes from a recent libgcj merge. We haven't yet merged the character
conversions of the two libraries. libgcj does explicitly define aliases
for the different encoding aliases. Classpath currently doesn't.
But see below.
> Fix:
> ----
> "ISO-8859-1" is the string used in the (Java) documentation.
> I think the Encoder and Decoder classes should be renamed
> from Encoder8859_1 to EncoderISO-8859-1 and so on.
You can also define the System property
"gnu.java.io.encoding_scheme_alias.ISO-8859-1" to have the value "8859_1".
See gnu/java/io/EncodingManager.java how this is implemented.
> How did it happen:
> ------------------
> I executed SpecApplication from the SpecJVM benchmark suite
> on my Jaos VM.
Could you try the test with the above workaround?
If that works we should at least by default define a couple of those
System property aliases for Classpath now until we actually merge character
conversions with libgcj.
Thanks,
Mark
--
Stuff to read:
<http://www.toad.com/gnu/whatswrong.html>
What's Wrong with Copy Protection, by John Gilmore