Bug ID: JDK-8142440 String folding stops when a non-constant object is reached

Versions (Unresolved/Resolved/Fixed)

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.

Other
tbd_majorUnresolved

Even after JDK-8134007, it seems javac only folds String-like constants from left to right, and it breaks as soon as non-constant is reached. See e.g.:

public class StaticStringConst {

        static final int INT = 42;
        static final Object OBJ = new Object();
        static final String STR = "Foo";

        public static String m1() {
                return "" + INT + STR + OBJ;
        }

        public static String m2() {
                return "" + STR + INT + OBJ;
        }

        public static String m3() {
                return "" + OBJ + INT + STR;
        }

        public static String m4() {
                return "" + OBJ + STR + INT;
        }
}

m1() folds nicely to "42Foo" + OBJ, but m2() folds only to OBJ + 42 + "Foo".

There are many layers of string folding in the compiler; the first occurs in the parser - and only deals with string literals; in this case, as there's no more than just one string literal, the parser folder will not do anything. The parser folder is the first level of defense against big files that are concatenation of string constants (which tend to be pretty common in Java EE space) - and the goal there is to cut down the cost of the recursive representation for string concatenation - as it doesn't scale (of course a better long term goal would be to have an array-based representation of a string concatenation so that parser folding will then be unnecessary). The second layer of folding occurs during type-checking - in fact the parser has no clue as to whether OBJ or STR are constants - you need the type-checker for that. And the type-checker folding analysis is dumb in the same way the old parser logic was: it folds constants from left to right and stops when a non-constant is encountered: it is an all or nothing approach. That said - I would argue that fixing this is less important than fixing the parser; by far the most common case was to have big files which were concatenating string literals together (mostly to build a configuration of some sort). While fixing this new case is still important, I don't think that real world code could reach level of constant folding (not visible to the parser) that are high enough to tank javac.

11-11-2015

Since JDK-8134007 was done by you, Maurizio, the initial assignment goes to you :)

10-11-2015