classpath
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]