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

Suggested rewrite for Integer.toString and Long.toString and new functionality

XMLWordPrintable

    • 1.0.2
    • sparc
    • solaris_1

      The existing code for toString in classes Integer and Long is quite convoluted.
      Also, signed output for non-decimal radices is often not what is desired;
      witness the recent rewrite of toString for class Object.

      I propose, first of all, that a method reverse be added to class StringBuffer,
      making that operation much cheaper:

          public synchronized StringBuffer reverse() {
      copyWhenShared();
      int n = count - 1;
      for (int j = (n-1)>>1; j >= 0; --j) {
      char temp = value[j];
      value[j] = value[n-j];
      value[n-j] = temp;
      }
      return this;
          }

      Then replace the code for toString in class Integer with the following code:

          public static String toString(int i, int radix) {
              if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX)
      radix = 10;
      StringBuffer buf = new StringBuffer(radix >= 8 ? 12 : 33);
      boolean negative = (i < 0);
              if (!negative)
      i = -i;
      while (i <= -radix) {
      buf.append(Character.forDigit(-(i % radix), radix));
      i = i / radix;
      }
      buf.append(Character.forDigit(-i, radix));
      if (negative) buf.append('-');
              return buf.reverse().toString();
          }

          public static String toHexString(int i) {
      return toUnsignedString(i, 4);
          }

          public static String toOctalString(int i) {
      return toUnsignedString(i, 3);
          }

          public static String toBinaryString(int i) {
      return toUnsignedString(i, 1);
          }

          private static String toUnsignedString(int i, int shift) {
      StringBuffer buf = new StringBuffer(shift >= 3 ? 11 : 32);
      int radix = 1 << shift;
      int mask = radix - 1;
      do {
      buf.append(Character.forDigit(i & mask, radix));
      i >>>= shift;
      } while (i != 0);
              return buf.reverse().toString();
          }

      and replace the code for toString in class Long with the following code:

          public static String toString(long i, int radix) {
              if (radix < Character.MIN_RADIX || radix > Character.MAX_RADIX)
      radix = 10;
      StringBuffer buf = new StringBuffer(radix >= 8 ? 23 : 65);
      boolean negative = (i < 0);
              if (!negative)
      i = -i;
      while (i <= -radix) {
      buf.append(Character.forDigit((int)(-(i % radix)), radix));
      i = i / radix;
      }
      buf.append(Character.forDigit((int)(-i), radix));
      if (negative) buf.append('-');
              return buf.reverse().toString();
          }

          public static String toHexString(long i) {
      return toUnsignedString(i, 4);
          }

          public static String toOctalString(long i) {
      return toUnsignedString(i, 3);
          }

          public static String toBinaryString(long i) {
      return toUnsignedString(i, 1);
          }

          private static String toUnsignedString(long i, int shift) {
      StringBuffer buf = new StringBuffer(shift >= 3 ? 22 : 64);
      int radix = 1 << shift;
      long mask = radix - 1;
      do {
      buf.append(Character.forDigit((int)(i & mask), radix));
      i >>>= shift;
      } while (i != 0);
              return buf.reverse().toString();
          }

      Then the definition of toString in class Object may be written as follows:

          public String toString() {
              return getClass().getName() + "@" + Integer.toHexString(hashCode());
          }

      By the way, Frank, if that high-order bit still bugs you, the thing to do is
      to change the definition of hashCode by toggling the high-order bit.
      (A weirder thing to do would be to xor the address of the object with the
      address of some known object, such as the Class object for class Object.
      This might achieve the desired effect of reducing the size of the hash code
      in a more portable fashion.)

            never Tom Rodriguez
            duke J. Duke
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: