JDK-6221056 : (cs) CharsetEncoder.encode(ByteBuffer) should call flush(ByteBuffer)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.2,5.0,5.0u21
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2005-01-25
  • Updated: 2017-05-16
  • Resolved: 2005-09-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b53Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
 

Attached JISTest.java to reproduce NIO problem.

On my environment Java(TM) 2 Runtime Environment, Standard Edition (build 

1.5.0-b64), i got the following result. 

 

Original:

0000: 1B 24 42 46 7C 4B 5C 38   6C 1B 28 42

 

Decoded and Encoded by NIO:

0000: 1B 24 42 46 7C 4B 5C 38   6C 00 00 00

 

This result means that NIO iso-2022-jp converter does not add

the escape sequence '1B 28 42' to the end of japanese characters

'46 7C 4B 5C 38 6C', just fills '00 00 00'.

According to iso-2022-jp specification(rfc1468), the escape

sequence '1B 28 42', i.e. 'ESC ( B' is used to switch back to

ASCII mode. and so, '00 00 00' is still handled japanese characters,

then is interpreted broken japanese characters.
###@###.### 2005-1-25 01:51:29 GMT

Here is a test case
=================================JISTest.java=========
import java.nio.*;
import java.nio.charset.*;
import sun.misc.HexDumpEncoder;

public class JISTest {

  public static void main(String args[]) {

    HexDumpEncoder dumper = new HexDumpEncoder();

    String jisx0208 = "\u65e5\u672c\u8a9e";

    try{
      byte[] b = jisx0208.getBytes("ISO-2022-JP");
      System.out.println("Original: ");
      System.out.println(dumper.encode(b));

      System.out.println("");

      System.out.println("Decoded and Encoded by NIO: ");
      Charset iso2022jp = Charset.forName("ISO-2022-JP");
      CharsetDecoder decoder = iso2022jp.newDecoder();
      ByteBuffer jpBytes = ByteBuffer.wrap(b);
      CharBuffer jpChars = decoder.decode(jpBytes);
      CharsetEncoder encoder = iso2022jp.newEncoder();
      ByteBuffer jpBytes2 = encoder.encode(jpChars);
      System.out.println(dumper.encode(jpBytes2.array()));

    } catch (Exception e) {
      e.printStackTrace();
    }
  }
}

###@###.### 2005-1-26 00:47:21 GMT

Comments
EVALUATION The test case JISTest.java appears to be missing. It should be able to reproduce this kind of failure in just a few lines of Java code. Please provide. ###@###.### 2005-1-26 00:18:39 GMT Added the testcase in description. ###@###.### 2005-1-26 00:47:21 GMT Charset-X-Coder $code$(ByteBuffer) tries to call flush, but the logic is incorrect. ###@###.### 2005-2-10 18:32:43 GMT Bug 6227608: (cs) Charset-X-Coder.flush cannot be reinvoked in case of overflow is a problem with flush being called too many times, while this bug is a problem with it not being called enough, so 6227608 is, in practice, a prerequisite for fixing this bug, since a fix to this bug will cause flush to be (correctly) called more often, causing the other bug to be tickled. ###@###.### 2005-2-11 17:58:03 GMT
26-01-2005