Pattern Matching Subtypes

[Fabio Yasuo Yamashita]

Hi there!

I am preparing for the java 17 exam and and studying the ocp 17 book. The page 108 says pattern matching must be a subtype and cannot be the same type but I wrote this piece of code in eclipse and it seems to work just fine

Integer x = 123;
if(x instanceof Integer data) { It works ! now I am confuse about it because the book states that it doesn't
}

What am I missing here?

[Mike Simmons]

It sounds like the book is simply wrong on page 108.  Or maybe it was misunderstood?  What exactly does the book say there?

[Fabio Yasuo Yamashita]

Baiscally the book says the pattern variable must be a subtype of the variable on the left side of the expression. It cannot be same.

Integer value = 123;

if(value instanceof Integer) {} compiles
if(value instanceof Integer data) {}  DOES NOT COMPILE. Here is strange because I wrote exactly the piece of code and it compiles.  

[Paul Clapham]

It looks to me as if the error message might possibly be referring to the rule that the subtypes used in the switch statement are supposed to cover the type of the switch expression exhaustively. So it would help to know what the error message says.

Also, the pattern matching for switch project was a preview until Java 21, so it's possible that this was one of the features which was modified in that long process. So you should be using the Java 17 compiler to match the exam and not Java 18 and later.

I also didn't see anything in the original JEP which says that the type of the case expression has to be a proper subtype of the type of the switch expression, and that the two couldn't be the same. But perhaps I missed that.

[Mike Simmons]

Fabio Yasuo Yamashita wrote:Baiscally the book says the pattern variable must be a subtype of the variable on the left side of the expression. It cannot be same.

Does the book say that the code with Integer does not compile?  Or does it just say that the type of the instanceof needs to be a subtype of the type of the variable?  Does it say that the types can't be the same?  Or did you just infer that from "subtype"?  It would really help to know exactly what the book said.

In an expression like

if (x instanceof Foo)

the type Foo needs to be a subtype of the declared type of x.  But you need to know that "subtype" includes being the same type.  E.g. a Dog is an Animal and a Cat is an Animal, but an Animal is also an Animal.  That's the way "subtype" is defined.

[Paul Anilprem]

There has been a change in the behavior of instanceof from Java 17 to Java 21. In Java 17, the type expression on the right hand side of the instanceof operator, when it is used for pattern matching (but not when it is used just for type comparison), must be a subtype of the type of the variable given on the left hand side. Java 21 does not impose this restriction.

[Mike Simmons]

Excellent call out - thank you, Paul A.

Fabio, if you're studying for Java 17, it's probably a good idea to be running JDK 17 when you're testing things.  Usually, it's OK to use a later version.  But in this case, they later allowed something that was initially not allowed.  If you try compiling with JDK 17, you should see the error you expected.

Thinking more though, I think that if the book says something like "the pattern variable must be a subtype of the variable on the left side of the expression" (still haven't seen an actual quote), then it's still wrong here.  Because the pattern variable (right hand side) may actually be totally unrelated to the type of the expression (left hand side).

  public static class Foo {}
  
  public static void main(String... args) {}
    Foo f = new Foo();
    if (f instanceof Serializable s) {
    }
  }

The compiler will accept this, because it knows that it's theoretically possible for a Foo instance to also implement Serializable.  It would have to be a subclass, and that's not what we have here, obviously.  But if the compiler considers only the type of the expression f, which is Foo, and the type of the pattern s, which is Serializable... considering only those things, and the declarations of Foo and Serializable... it is possible that a Foo could also be Serializable.  So it's allowed.

If you make class Foo final, then it becomes impossible, and is not allowed.  Because Foo itself is not Serializable, and no other subclass of Foo can exist, so no Foo is Serializable, ever.

This is pretty similar to the rules for casting - if a cast is probably impossible based on the types involved, it will not be allowed.  If it's at least theoretically possible based on the type, it's allowed.  It may fail at runtime, but it's allowed.

[Jeanne Boyarsky]

This is the actual text and example from the Java 17 book:

The type of the pattern variable must be a subtype of the variable on the left side of the
expression. It also cannot be the same type. This rule does not exist for traditional instanceof
operator expressions, though. Consider the following two uses of the instanceof operator:

Integer value = 123;
if(value instanceof Integer) {}
if(value instanceof Integer data) {} // DOES NOT COMPILE

While the second line compiles, the last line does not compile because pattern matching
requires that the pattern variable type Integer be a strict subtype of Integer .

[Jeanne Boyarsky]

Also note that this is in chapter 3 of the book before interfaces  have been covered. So it is covering the basics.

Chapter 7 has a section about instanceof which covers the interface implications.  I believe that is what Mike is referencing in hist post about the section not being complete. It's not because it's split into two!

[Mike Simmons]

Thanks for the clarification, Jeanne!

[Crystal Kirscht]

I discovered the same thing. Only it only compiles in Eclipse and in VSCode (which both use Java 17). However when I run Java from the command line on the same code it does not compile. I'm not sure what is different

[Jeanne Boyarsky]

Crystal Kirscht wrote:I discovered the same thing. Only it only compiles in Eclipse and in VSCode (which both use Java 17). However when I run Java from the command line on the same code it does not compile. I'm not sure what is different

Can you type

java --version

My guess is your command line is using Java 21 and triggering the change in behavior Paul mentioned.

[Crystal Kirscht]

Jeanne Boyarsky wrote:

Crystal Kirscht wrote:I discovered the same thing. Only it only compiles in Eclipse and in VSCode (which both use Java 17). However when I run Java from the command line on the same code it does not compile. I'm not sure what is different

Can you type

java --version

My guess is your command line is using Java 21 and triggering the change in behavior Paul mentioned.

It is actually on the command line that it is NOT compiling.

D:\MyWorkspace\HelloWorld\src\chapter3>javac PatternMatching.java
PatternMatching.java:38: error: expression type Integer is a subtype of pattern type Integer
               if(value instanceof Integer data) {
                        ^
1 error

D:\MyWorkspace\HelloWorld\src\chapter3>java --version
java 17.0.4.1 2022-08-18 LTS
Java(TM) SE Runtime Environment (build 17.0.4.1+1-LTS-2)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing)

It is in Eclipse and VSCode where it IS compiling. But I know those are using Java 17 as I have not installed any other versions and I have checked the settings in Eclipse (I'm not sure where they are in VSCode). I've attached screenshots of the code and jre settings in eclipse

[Enrico Giurin]

Fabio Yasuo Yamashita wrote:
It works

No, it does not!

    Integer x = 123;
    if(x instanceof Integer data) {

    }

It generates this compiler error:

Pattern type 'Integer' is the same as expression type

[Campbell Ritchie]

Your code compiles and runs on JShell, version 21. Which version of Java® are you using?

[Enrico Giurin]

Campbell Ritchie wrote:Which version of Java® are you using?

JDK 17, the version of Java for the OCP 17 exam.

[Mike Simmons]

Paul Anilprem previously pointed out that in Java 17 this is an error, and in Java 21 it is not.  So it's expected that for Java 17 it should error.  We never found out what version the original poster was using... but it's probably not Java 17.

Incidentally, you can get the same error message from jdk 21 or later by setting the language level to 17 - e.g.

javac -source 17 MyClass.java