[Investigation] Use pattern matching for instanceof at module jdk.compiler
Brian Goetz
brian.goetz at oracle.com
Wed Apr 21 17:08:49 UTC 2021
Just like keeping the JDK codebase up to "modern Java" standards (an
ongoing task!), we should do the same with the compiler codebase. There
is one constraint; we must wait one extra version to use new (permanent)
language features in the compiler, because the compiler must be compiled
with a boot JDK which is of the previous version. So if pattern
matching became permanent in 16, we can start to use it in the compiler
in 17.
In the JDK, we've set the following guidelines for these sort of
refactoring patches:
- Each patch should focus on _one_ refactoring (e.g., replace
traditional instanceof with pattern). This reduces the cognitive load
on reviewers.
- Each patch should have a single review domain. This is not an issue
for the compiler, but is an issue for the JDK, where `java.base` has
generic library code, security code, UI code, each of which requires
review by separate skillsets.
- Patches shouldn't be "too big". This argues for breaking down by
groups of related packages if the whole thing is too big.
- No API changes.
- Patches should be, to the degree possible, produced entirely by
automated refactoring tools. Resist the urge to make small manual
tweaks to make the code look better. Again, this makes it much easier
for reviewers to conclude "nothing to see here."
On 4/21/2021 12:51 PM, Guoxiong Li wrote:
> Hi all,
>
> The JEP-394[1] implemented the `Pattern matching for instanceof` at
> JDK 16. It is a good specification. Many packages or modules of the
> JDK begin to use it, such as package `java.time`[2][3]. I think it is
> good for the javac compiler to use it, too.
>
> Here are some issues we need to consider or something I want to confirm.
>
> 1. What's your opinion about this idea? Is it necessary?
> 2. Is somebody doing the same thing locally? If not, I would like to
> do that.
> 3. Is it good to revise the whole module `jdk.compiler` by submitting
> a big patch? Or, should we separate it into several sub-tasks
> according to different packages?
> 4. Do the related modules, such as `java.compiler`, also need to be
> revised?
>
> Any idea is appreciated.
>
> [1] https://openjdk.java.net/jeps/394 <https://openjdk.java.net/jeps/394>
> [2] https://bugs.openjdk.java.net/browse/JDK-8263668
> <https://bugs.openjdk.java.net/browse/JDK-8263668>
> [3] https://github.com/openjdk/jdk/pull/3170
> <https://github.com/openjdk/jdk/pull/3170>
>
> ----
> Best Regards,
> Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210421/c1746918/attachment-0001.htm>
More information about the compiler-dev
mailing list