JDK-8044612 : StringIndexOutOfBoundException in NativeRegExp.appendReplacement
  • Type: Bug
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-06-03
  • Updated: 2015-06-01
  • Resolved: 2014-06-03
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.
8u20Fixed 9 b17Fixed
Related Reports
Duplicate :  
Chris Pettit wrote to nashorn-dev alias:

----- email --------


I believe I have found a bug in NativeRegExp.appendReplacement around handling of '$'. Per [1], A '$' in newstring that does not match one of the forms in Table 22 should be left as is. The appendReplacement function handles this correctly for most cases, but breaks with the following input:

    jjs> "a".replace("a", "$")
    java.lang.StringIndexOutOfBoundsException: String index out of range: 1

The problem is that appendReplacement assumes that a character will follow the '$' character:

        int cursor = 0;
        Object[] groups = null;

        while (cursor < replacement.length()) {
            char nextChar = replacement.charAt(cursor);
            if (nextChar == '$') {
                // Skip past $
                nextChar = replacement.charAt(cursor);    // This line fails for the above input, there is no character as index 1.

While the code should be using "$$" as a replacement text, the spec seems to indicate that "$" should work if no characters follow. I tested this with a few JS engines (node, chrome, firefox) and all handle this by replacing "a" with "$", which conforms to my reading of the spec.


[1]: http://www.ecma-international.org/ecma-262/5.1/#sec-

---- email ends ----

I confirmed that the issue is reproduced with the tip of jdk8u-dev as well as  jdk9 (in addition to jdk8 GA).