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

Indy string concat changes order of operations

    XMLWordPrintable

Details

    • CSR
    • Resolution: Approved
    • P4
    • 19
    • tools
    • None
    • behavioral
    • minimal
    • Hide
      The change makes the implementation consistent with behaviour required by the specification, by fixing a regression introduced in JDK 9. There is some compatibility risk that code using JDK 9 or newer could have come to depend on the incorrect behaviour. If the bug is left unfixed, there is a risk that existing code still using Java 8 will be broken when it upgrades to the latest versions.
      Show
      The change makes the implementation consistent with behaviour required by the specification, by fixing a regression introduced in JDK 9. There is some compatibility risk that code using JDK 9 or newer could have come to depend on the incorrect behaviour. If the bug is left unfixed, there is a risk that existing code still using Java 8 will be broken when it upgrades to the latest versions.
    • Class file construct
    • Implementation

    Description

      Summary

      This change causes the operands of string concatenation expressions to be evaluated and converted to strings in the correct order when using the invokedynamic-based strategies introduced in JEP 280.

      Problem

      JLS 15.18.1 requires string conversion to be performed on the operands of a string concatenation expression, and JLS 15.7.1 requires the operands to be fully evaluated in left-to-right order. The current behavior of the invokedynamic string concatenation strategies is to evaluate all operands, and then separately convert them all to strings. The correct behavior is to evaluate each argument and eagerly convert it to a string, in left-to-right order.

      Solution

      The solution is for the invokedynamic-based strategies to convert the operands to strings as they are evaluated, and before they are passed to the invokedynamic call site, to preserve the required evaluation order.

      For some well-known types whose string representation is known to be idempotent (including primitive types, their boxes, and java.lang.String) the eager string conversion may be skipped.

      Specification

      No specification changes are required.

      The proposed change to restore the behavior of the implementation to match the specification can be found in https://git.openjdk.java.net/jdk/pull/5844.

      Attachments

        Issue Links

          Activity

            People

              cushon Liam Miller-Cushon
              cushon Liam Miller-Cushon
              Aleksey Shipilev
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: