JDK-8035787 : SourcePositions are wrong for Strings concatenated with '+' operator
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7,8,11,14,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-25
  • Updated: 2023-01-05
  • Resolved: 2020-04-07
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.
JDK 11 JDK 15
11.0.19-oracleFixed 15 b18Fixed
Related Reports
Relates :  
JDK-8031725 - No way to detect synthetic com.sun.source.tree.Tree's
Relates :  
JDK-8024098 - javac syntax tree should more closely model the source code
Description
SourcePositions reports the wrong start/end offsets for ExpressionTrees containing Strings concatenated with '+' operator, and in some cases (annotation arguments) the end offset is -1.
Compile and run the attached program with tools.jar in the classpath.
It prints out:
Annotation argument: + "ll") pu
StartOffset: 22
EndOffset: -1
Field init: + "ll"
StartOffset: 86
EndOffset: 92
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/d5b6b9733f13 User: cushon Date: 2020-04-07 21:43:18 +0000
07-04-2020
> > the attribute gets synthetic 'value = <expression>', and its end pos is not valid > > -XDallowStringFolding=false ... does not work for the annotation argument I get correct end positions for the string literal in the annotation, just not for the synthetic assignment expression. You have to request the end position for the string literal directly, though, i.e.: ExpressionTree argument = annotation.getArguments().get(0); argument = ((AssignmentTree) argument).getExpression(); that gives me: Annotation argument: "a" + "ll" StartOffset: 18 EndOffset: 28 Field init: "a" + "ll" StartOffset: 82 EndOffset: 92 I think it's worth adding a regression test for the issue with start positions that was fixed by JDK-8134007, but otherwise itlooks like this is working as intended.
06-04-2020
The same positions are now reported for the field initializer with and without string folding enabled, perhaps as a result of JDK-8134007: Class1 compiled and run with JDK 11+28: ``` Field init: "a" + "ll" StartOffset: 82 EndOffset: 92 ``` With a patch to Class1 to disable string folding: 110a111 > options.add("-XDallowStringFolding=false"); ``` Field init: "a" + "ll" StartOffset: 82 EndOffset: 92 ```
28-08-2018
-XDallowStringFolding=false works great for the field initializer. However it does not work for the annotation argument, still wrong starting offset. The new output is: Annotation argument: + "ll") pu StartOffset: 22 EndOffset: -1 Field init: "a" + "ll" StartOffset: 82 EndOffset: 92
25-02-2014
The problem with annotations is actually not related to string concatenation (IMO) - the attribute gets synthetic 'value = <expression>', and its end pos is not valid. So that fits JDK-8031725 and JDK-8024098. Regarding the string concatenation, I think the primary problem is string folding - it can currently be disabled by using '-XDallowStringFolding=false' option. Covered by JDK-8024098 as well, I think, but I'll keep this bug specifically for string folding, as disabling it is not free and we need to decide what to do.
25-02-2014