Type pattern and raw type

[Brian Goetz]

It's definitely a mistake that we do nothing here.

There are two options.  The obvious is to simply raise a raw warning; 
this is a straightforward spec/impl fix which we can easily do.

The other option is to do as we did with method refs, where we apply 
type inference to an unadorned `Foo` pattern.  But, if the user wanted 
type inference, they'd have said `var`.  So I think the right move is to 
issue the warning.

On 3/15/2021 7:08 AM, Remi Forax wrote:
> Hi, currently when there is an instanceof + type pattern with a raw type,
> javec doesn't raise any warning (oops), worst it compiles because i believe it should not, but for that, the spec has to be amended.
>
>    interface Foo<T> {
>      void set(T t);
>    }
>
>    class FooImpl implements Foo<String> {
>      private String value;
>
>      @Override
>      public void set(String s) {
>        value = s;
>      }
>    }
>
>    public static void main(String[] args) {
>      Object o = new FooImpl();
>      if (o instanceof Foo foo) {
>        foo.set(3);
>      }
>    }
>
> The JLS 14.30.2 says
> "An expression, e, that is not the null literal is compatible with a type test pattern of type T if e can be converted to type T by a casting conversion (5.5), and the casting conversion does not make use of a narrowing reference conversion which is unchecked (5.1.6.2)."
>
> Unchecked conversions are forbidden because of type pollution, that why you can not write
>    if (o instanceof Foo<Integer> foo) {
>
> Raw type conversions also leads to type pollution, so i think that a type pattern with a raw type should be forbidden too.
>
> So at least, javac should raise a warning and IMO the spec should be amended to fordid raw types too.
>
> regards,
> Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210315/5b6c5196/attachment.htm>