Bug 35482

I'll investigate this further.

I've managed to duplicate this here.  Note that it needs the JDK 1.4 compatibility package to obtain this error.  Without this, it complains about a missing JMX class.  In the long term, we should aim to run without the compatibility package too.

The error seems to be related to the expected cloning behaviour.

After hours of chasing, I've found it's nothing to do with JMX at all or our implementation.  The bug arises from Ian's change to String.toLowerCase(), which now eats characters when they begin with lowercase letters.  Thus, the lowercase variants of the descriptor keys become broken.

       int i = count;
        int x = offset - 1;
        while (--i >= 0)
          {
            char ch = value[++x];
            if (ch != Character.toLowerCase(ch))
              break;
          }
        if (i < 0)
          return this;

        // Now we perform the conversion. Fortunately, there are no
        // multi-character lowercase expansions in Unicode 3.0.0.
        //char[] newStr = (char[]) value.clone();
        char[] newStr = new char[count];
        VMSystem.arraycopy(value, offset, newStr, 0, count - (x - offset));
        do
          {
            char ch = value[x];
            // Hardcoded special case.
            newStr[x - offset] = Character.toLowerCase(ch);
            x++;
            //newStr[x++] = Character.toLowerCase(ch);
          }
        while (--i >= 0);
        // Package constructor avoids an array copy.
        return new String(newStr, 0, count, true);
        //return new String(newStr, offset, count, true);

The lowerCase algorithm above calculates a value of x which will differ depending on how many lowercase letters are at the start of the string.
The upperCase algorithm works differently, taking account of larger lowercase letters and doesn't optimise by only uppercasing non-uppercased starting letters.  Thus it doesn't seem to suffer from this bug.

A string which starts with an uppercase letter will lowercase fine, because the offset, x, will be 0 (the while loop immediately fails, incrementing x just once).  However a string like 'descriptorType' (which is the lookup that fails in this bug) becomes 'desctype' instead.

I'll attach a testcase that demonstrates this.

Created attachment 15583 [details]
Minimal test case

Created attachment 15584 [details]
Fix

CVSROOT:        /sources/classpath
Module name:    classpath
Changes by:     Andrew John Hughes <gnu_andrew> 08/05/06 02:42:05

Modified files:
       .              : ChangeLog
       java/lang      : String.java

Log message:
       2008-05-06  Andrew John Hughes  <gnu_andrew@member.fsf.org>

               PR classpath/35482
               * java/lang/String.java:
               (toLowerCase()): Fix calculation of number
               of characters to copy.
               (toLowerCaseTurkish()): Likewise.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9595&r2=1.9596
http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/String.java?cvsroot=classpath&r1=1.89&r2=1.90

Yes, the bug is fixed.  Thanks.