Showing content from https://github.com/pmd/pmd/issues/2159 below:
[java] Prepare for JDK 14 · Issue #2159 · pmd/pmd · GitHub
For now the following grammar-related JEPs are proposed for JDK 14:
- Preview features:
- New standard features
(Full list of jeps target for 14: https://openjdk.java.net/projects/jdk/14/)
EA builds of jdk14: https://jdk.java.net/14/
Switch exprs
Nothing much to do here, just make it known that the YieldStatement node will be fully supported I guess.
https://docs.oracle.com/javase/specs/jls/se13/preview/switch-expressions.html
Pattern matching
- Grammar is straightforward, possibly just a new node TypeTestPattern:
void TypeTestPattern():
{}
{
Type() VariableDeclaratorId()
}
- InstanceOfExpression can take such a pattern as RHS
- Grammar on java-grammar needs to be updated, possibly use a new PatternExpr node to wrap the pattern on the RHS, like TypeExpr does for types
- Scoping rules of the binding variable are very complicated. I'm not sure we should even try to tackle them fully on master.
Records
The grammar is pretty straightforward: https://openjdk.java.net/jeps/359#Grammar
JLS updates: http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191121/specs/records-jls.html
A priori this would entail the following changes on the 6.x branch:
- New nodes RecordDeclaration, RecordComponent, RecordBody, RecordBodyDeclaration
- Among those, RecordBodyDeclaration will be ousted from 7.x like the other *BodyDeclaration, but this is work for later on java-grammar
- New node RecordConstructorDeclaration?
- The only difference in grammar from regular constructor declarations, is that no formal parameters are allowed. I don't think we can just make FormalParameters optional on ConstructorDeclaration, because it would create NPEs everywhere.
- So maybe we need to create a new node
- We also need to update the symbol table
- In record constructor declarations which have no formal parameter list, it's assumed that there is a parameter list which looks like the record components. So each record components declares on the one hand a field, and OTOH one distinct formal parameter for each record constructor declaration.
- This is pretty exotic for our symbol table, idk how best it would be implemented on 6.x. On 7.x it would probably be nice to use an implicit FormalParameters node (a node with text length 0), so that the AST is a bit desugared(1).
- Now that I think about it the current symbol table already creates some formal parameters to represent eg the implicit
valueOf function in enums. It just doesn't insert them in the tree. So maybe we can do that on master?
Schedule
After writing this up, I realised that general availability is not due for another 3 months (March 17). Maybe by then we'll be working entirely on the 7.0.x branch? Idk
(1) btw implicit nodes would also iron out some corner cases of the AST, eg enum constants which have no argument list - for now they're nullable, but they wouldn't be if it were implicit
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4