JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1) (original) (raw)
Xueming Shen xueming.shen at oracle.com
Thu Apr 10 18:08:50 UTC 2014
- Previous message: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)
- Next message: JDK 9 RFR of JDK-8039864: Fix fallthrough lint warnings in other libs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This fix is to "un-do" a previous changeset (8036848), in which it replaces the use of deprecated String.getBytes(int,int,byte[],int) method with String.getBytes() (which uses the default platform default charset), therefor causes a behavioral change. This one is to undo that change to go back to the "platform neutral" behavior. String.getBytes(int,int,byte[],int) and String.getBytes(iso-8859-1) are functionally equivalent when encoding (from charset's decoding/encoding perspective/term, it's "decoding" from base64's term) base64 alphabets.
-Sherman
On 04/10/2014 10:54 AM, Mike Duigou wrote:
Shouldn't we be using the platform default character set rather than iso8859-1?
This change will change the charset used for all platforms not using iso885901 as their default. It is certainly odd that sun.misc.CharacterEncoder(byte) and sun.misc.CharacterDecoder(String) are not symmetrical but this seems like a serious historical wart we might need to preserve. Mike On Apr 9 2014, at 18:19 , Brian Burkhalter<brian.burkhalter at oracle.com> wrote:
Hello,
Issue: https://bugs.openjdk.java.net/browse/JDK-8039474 Patch: http://cr.openjdk.java.net/~bpb/8039474/webrev.00/ The change is to specify the charset for the String where none had been before. The extant test sun/misc/Encode/GetBytes.java appears to suffice for this. Thanks, Brian
- Previous message: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)
- Next message: JDK 9 RFR of JDK-8039864: Fix fallthrough lint warnings in other libs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]