RFR: 8250625: Compiler implementation of Pattern Matching for instanceof (Final)

Jan Lahoda jlahoda at openjdk.java.net
Tue Oct 20 10:09:25 UTC 2020

On Tue, 20 Oct 2020 03:02:03 GMT, Vicente Romero <vromero 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.
> test/langtools/tools/javac/patterns/BindingsTest1.java line 28:
>> 26:  * @bug 8231827
>> 27:  * @summary Basic tests for bindings from instanceof
>> 28:  * @compile BindingsTest1.java
> the @compile can be removed

I guess I prefer to keep @compile for javac non-programatic tests. The reason is that, for these tests, we can expect
we modify javac, but not the test. And if @build (implicit or explicit) is used, the test will not be re-compiled
unless their timestamp changes. So we can actually execute an older (already built) version of the test's class file,
instead of a newly built class file, which would reflect the changes in javac. So, for tests like this, I prefer to
have an explicit @compile, as that ensures the file is compiled every time, regardless how the working directories are
set-up, etc.


PR: https://git.openjdk.java.net/jdk/pull/559

More information about the compiler-dev mailing list