JDK-8024098 : javac syntax tree should more closely model the source code
  • Type: Sub-task
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-08-31
  • Updated: 2021-06-15
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
Related Reports
Relates :  
JDK-8268850 - Detect inferred local variable types in AST
Relates :  
JDK-7077364 - (javac) Starting positions of ClassTree for enum constants
Relates :  
JDK-8214902 - Pretty-printing marker annotations add unnecessary parenthesis
Relates :  
JDK-8035787 - SourcePositions are wrong for Strings concatenated with '+' operator
Relates :  
JDK-8044853 - Attr synthesizes nullcheck tree nodes
Relates :  
JDK-8076281 - Investigate compiler Tree API client's expectations for inferred elided types.
Relates :  
JDK-8031725 - No way to detect synthetic com.sun.source.tree.Tree's
Relates :  
JDK-8044555 - The Tree API gives no access to non-Javadoc comments
Description
Currently, some desugaring is done early, in the parser (e.g. enum constants) and MemberEnter (e.g. default constructors, super calls).

It would be better if the tree more closely modeled the source text (up until TransTypes and Lower).  This will mean adding more tree nodes.   The desugaring done today should effectively be done while creating the internal semantic data structures.

A nice goal/test would be to be able to take a source file, run it through parse() and analyze(), write out the tree, and get the same sequence of tokens found in the original file (i.e. ignoring changes in whitespace and comments.)
Comments
As noted in: http://mail.openjdk.java.net/pipermail/compiler-dev/2014-September/009019.html multiple variable declarations sharing the same type are represented as separate VariableTree: int a = 0, b = 1;
30-09-2014
Added JDK-8044853 -- Attr mutates the tree to add nullcheck nodes
04-06-2014
Yes, folding constant types should not be a problem (AFAIK, that produces types that work as normal types, but have the constant value in addition to that). Thanks for the try-with-resource example/problem.
15-04-2014
final on try-with-resources happens in JavacParser: protected JCTree resource() { JCModifiers optFinal = optFinal(Flags.FINAL); JCExpression type = parseType(); int pos = token.pos; Name ident = ident(); return variableDeclaratorRest(pos, optFinal, type, ident, true, null); } would maybe be better to set final on the VarSymbol, not on the tree itself
14-04-2014
Note that the resource variable in a try-with-resources statement is implicitly final.
14-04-2014
It has also been reported that javac modifies the modifiers in a try-with-resources. Here is evidence. Input: -----8<----- import java.io.*; class TWR { public void m() throws Exception { try (InputStream in = new FileInputStream("file")) { } } } ----->8----- tree after JavacTask.analyze() -----8<----- import java.io.*; class TWR { TWR() { super(); } public void m() throws Exception { try (final InputStream in = new FileInputStream("file");) { } } } ----->8-----
14-04-2014
folding constant types should be OK if it doesn't affect the tree
14-04-2014
there is also folding of constant types in Attr
14-04-2014
Known changes currently being done to ASTs before desugar: -folding of string literals (in JavacParser) - there is already an option to disable that ("allowStringFolding"). -generated default constructors (MemberEnter) -generated super constructor calls (Attr) -anonymous innerclasses (Attr and Flow): --adds constructor --the anonymous innerclass is a real ClassTree/JCClassDecl (already cast in the API - NewClassTree.getClassBody()), with its own extends/implements --desugaring of <encl>.new <something>. -annotation attributes "expansion" (adding 'value =', wrapping a singleton value into new array) -the enum constants are desugared into fields and their initializers (and anonymous innerclasses) in JavacParser -annotations after method's type parameters are merged into the modifiers, and so hard to separate from the annotations originating genuinely in modifiers (noted on the review for JDK-8038788).
14-04-2014