RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final) [v2]
Vicente Romero
vromero at openjdk.java.net
Wed Oct 21 03:16:23 UTC 2020
On Tue, 20 Oct 2020 12:03:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
>> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
>>
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current specification proposal)
>> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>> (as per current specification proposal)
>> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>> and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>> Tree, etc.
>>
>> This change will not be integrated until JEP 394 is targetted.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since
> the last revision:
> - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
> - Merge branch 'master' into patterns-instanceof3
> - Fixing more tests.
> - Correcting positions.
> - Improve the AST model.
> - Merge branch 'master' into patterns-instanceof3
> - Updating @since tags.
> - Merge branch 'master' into patterns-instanceof3
> - Cleaning up preview comments in javadoc.
> - Merge branch 'master' into patterns-instanceof3
> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/062b3b15...5978bca0
Changes requested by vromero (Reviewer).
src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 34:
> 32: * @since 16
> 33: */
> 34: public interface PatternTree extends Tree {}
I think that this interface is there for forward compatibility, it is still weird to have an empty interface and then
an empty class in JCTree implementing this interface. Doesn't it make sense to move any method from BindingPatternTree
up to this interface? I think that if having this empty interface is deemed unavoidable then, just an idea, we should
acknowledge the fact that this is a forward looking interface.
src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 29:
> 27:
> 28: /**
> 29: * A tree node used as the base class for the different kinds of
the javadoc seems to need an update
-------------
PR: https://git.openjdk.java.net/jdk/pull/559
More information about the core-libs-dev
mailing list