[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