Summary

Add a new level of indirection in the representation of case labels. More specifically, two new subinterfaces of CaseLabelTree are added (namely, ConstantCaseLabelTree and PatternCaseLabelTree), which then refer to the expression or pattern in the corresponding case label.

Problem

Under JEP 427, case label elements may be of the following kinds:

• constant case labels (e.g. case 5, or case "Hello");
• pattern case labels (case String s, or case Point(int x, int y))
• default case labels (default).

The Trees API models the case source element using the CaseTree interface, which holds a list of CaseLabelTrees, each of which is a label associated to the given case source element. Since, as shown above, there are different kinds of labels, a choice was made to make both ExpressionTree and PatternTree extend the CaseLabelTree interface.

This is suboptimal in two ways: first the change is very broad, since now all expressions, whether used in a pattern or not, acquire the new CaseLabelTree interface. Secondly, when guards became part of pattern case labels (rather than being a special kind of pattern themselves), it was necessary to augment all patterns with guard expressions, even if this feature is only really used when a pattern is used as a case label element. This is inconsistent with the rest of the API.

Solution

The following changes are proposed:

• ExpressionTree no longer extends CaseLabelTree. A new ConstantCaseLabelTree is introduced, which holds the constant expression of a case
• PatternTree no longer extends CaseLabelTree, and no longer holds a guard. A new PatternCaseLabelTree is introduced, which holds the pattern and its guard
• TreeScanner.visitCase currently uses CaseTree.getExpressions() to recurse into child nodes. We propose to change the visitor method to use CaseTree.getLabels() instead. As a consequence, all the new tree nodes will be visited when using TreeScanner.

The existing DefaultCaseLabelTree, which models the default case is unchanged.

Specification

The specdiff for the change is attached, and is also available for convenience here: http://cr.openjdk.java.net/~jlahoda/8287236/specdiff.00/overview-summary.html