Type pattern and raw type
Brian Goetz
brian.goetz at oracle.com
Mon Mar 15 13:28:26 UTC 2021
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>
More information about the amber-spec-experts
mailing list