Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8021560

(str) String constructors that take ByteBuffer

    Details

    • Type: Enhancement
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:

      Description

      A DESCRIPTION OF THE REQUEST :
        
      public String(ByteBuffer bytes, Charset cs);
      public String(ByteBuffer bytes, String csname);
      public int getBytes(byte[] dst, int offset, Charset cs);
      public int getBytes(byte[] dst, int offset, String csname);
      public int getBytes(ByteBuffer bytes, Charset cs);
      public int getBytes(ByteBuffer bytes, String csname);

      JUSTIFICATION :
      When using a direct ByteBuffers it is necessary to create an intermediate byte[] for passing to the constructor for a String. This result is extra potentially buggy code that generates garbage.

        Issue Links

          Activity

          Hide
          smarks Stuart Marks added a comment -
          Should be reasonably simple to reduce two copies (ByteBuffer -> byte[] -> String) down to one. Charset is necessary to provide the proper conversion of bytes into chars. A possibility is to use the system's default charset if a charset argument isn't provided, similar to existing byte[] constructor overloads.
          Show
          smarks Stuart Marks added a comment - Should be reasonably simple to reduce two copies (ByteBuffer -> byte[] -> String) down to one. Charset is necessary to provide the proper conversion of bytes into chars. A possibility is to use the system's default charset if a charset argument isn't provided, similar to existing byte[] constructor overloads.
          Hide
          alanb Alan Bateman added a comment -
          It would be preferable not to use the default charset as that would make the method sensitive to the locale (as the default charset is determined by on the locale).
          Show
          alanb Alan Bateman added a comment - It would be preferable not to use the default charset as that would make the method sensitive to the locale (as the default charset is determined by on the locale).
          Hide
          smarks Stuart Marks added a comment -
          Agreed, adding an API that uses the system's default charset is a bad idea. If we want to have an overload that doesn't take a Charset, it should default to UTF-8 instead. (The APIs in NIO follow this style.)
          Show
          smarks Stuart Marks added a comment - Agreed, adding an API that uses the system's default charset is a bad idea. If we want to have an overload that doesn't take a Charset, it should default to UTF-8 instead. (The APIs in NIO follow this style.)
          Show
          smarks Stuart Marks added a comment - Historical review threads: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028837.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-October/029214.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029672.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030512.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031700.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/033912.html Current review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051401.html

            People

            • Assignee:
              sherman Xueming Shen
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: