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
