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 core-libs-dev
mailing list