'one-sided' generics?

[Jay Chung]

Looking at the following code:

1.

List<String> l = new ArrayList(); //ok…
l.add(“a”); //ok
l.add(new Object()); //NOT COMPILE
String s = l.get(0); //ok

2.

List l = new ArrayList<String>(); //ok…
l.add(new Object()); //ok
String s = l.get(0); //NOT COMPILE - get() returns Object…

it seems like from 1. we have:
A: ObjectInstance<Type> o = new ObjectInstance(); is treated like ObjectInstance<Type> o = new ObjectInstance<Type>();
And from 2. we have:
B: ObjectInstance o = new ObjectInstance<Type>(); is treated like ObjectInstance o = new ObjectInstance();

But then I saw some other question which breaks these rules:

interface CourseFilter extends Predicate<String> {
    public default boolean test(String str) {
        return str.equals("Java");      
    }
}
Predicate p = new CourseFilter() { //*ok
    public boolean test(String s) {
        return s.contains("Java");
    }
};

in this case, I would've thought that line * follows rule B, but if that were the case, then it would be
Predicate p = Predicate(), which then should cause * to NOT COMPILE as it does not implement
public boolean test(Object o)
But it does compile ok...

Can someone confirm whether my interpretation of A and B are even correct and if not, are there some rules to follow with this kind of thing?

[Mike Simmons]

Jay Chung wrote:in this case, I would've thought that line * follows rule B, but if that were the case, then it would be
Predicate p = Predicate(), which then should cause * to NOT COMPILE as it does not implement
public boolean test(Object o)

Your interpretation is pretty good, but a little off.  In rule B, it's not that the compiler treats new ObjectInstance<Type>() as new ObjectInstance() for the entire statement.  Rather, it makes that substitution, ignoring the generic parameter, while evaluating the assignment part (the =).  So think of the compiler as looking at the expression in different parts.  First:

... new CourseFilter() { //*ok
    public boolean test(String s) {
        return s.contains("Java");
    }
}

This part makes sense on its own - a CourseFilter needs to have a boolean test(String).  Great!  The compiler is happy with this.

And then this part:

Predicate p = new CourseFilter() {...}

When the compiler looks at the assignment, it basically asks itself, can the thing on the right be treated as the thing on the left?  Which in this case means, can a Predicate<String> be treated as a Predicate?  The answer is yes, it's willing to ignore the generic part and let the assignment take place.  If you want to treat this as a raw Predicate, you can, the compiler will let you.  However that doesn't mean it's re-evaluating the entire right hand side to make it conform to the raw Predicate type.  The right hand is still a Predicate<String>, with a test(String) method.  And the assignment is allowed to happen.

Now at run time, you may still run into problems.  What happens if you run the following?

        System.out.println(p.test("Java"));
        System.out.println(p.test("Foo"));
        System.out.println(p.test(Integer.valueOf(42)));

[Jay Chung]

Mike Simmons wrote:

Jay Chung wrote:in this case, I would've thought that line * follows rule B, but if that were the case, then it would be
Predicate p = Predicate(), which then should cause * to NOT COMPILE as it does not implement
public boolean test(Object o)

Your interpretation is pretty good, but a little off.  In rule B, it's not that the compiler treats new ObjectInstance<Type>() as new ObjectInstance() for the entire statement.  Rather, it makes that substitution, ignoring the generic parameter, while evaluating the assignment part (the =).  So think of the compiler as looking at the expression in different parts.  First:

... new CourseFilter() { //*ok
    public boolean test(String s) {
        return s.contains("Java");
    }
}

This part makes sense on its own - a CourseFilter needs to have a boolean test(String).  Great!  The compiler is happy with this.

And then this part:

Predicate p = new CourseFilter() {...}

When the compiler looks at the assignment, it basically asks itself, can the thing on the right be treated as the thing on the left?  Which in this case means, can a Predicate<String> be treated as a Predicate?  The answer is yes, it's willing to ignore the generic part and let the assignment take place.  If you want to treat this as a raw Predicate, you can, the compiler will let you.  However that doesn't mean it's re-evaluating the entire right hand side to make it conform to the raw Predicate type.  The right hand is still a Predicate<String>, with a test(String) method.  And the assignment is allowed to happen.

Now at run time, you may still run into problems.  What happens if you run the following?

        System.out.println(p.test("Java"));
        System.out.println(p.test("Foo"));
        System.out.println(p.test(Integer.valueOf(42)));

Yeah makes sense, the last print line causes exception because LHS reference type determines what method is called, in this case test(Object o) since LHS uses no generics.

I also tested the opposite:

interface CourseFilter extends Predicate {
    public default boolean test(Object str) {
        return true;      
    }
}
public class Main {
	public static void main(String[] args) {
        Predicate<String> p = new CourseFilter() { //ok
            public boolean test(Object s) { //*
                return true;
            }
        };
        System.out.println(p.test("Java"));
        System.out.println(p.test(Integer.valueOf(42))); //NOT COMPILES - LHS determines call - test(String o)
    }
}

Looks like this breaks rule A (line *) and I'm guessing it's the same reason you just outlined for the opposite way - the compiler independently checks

... new CourseFilter() { //ok
    public boolean test(Object s) { //*
        return true;
    }
}

before independently checking

Predicate<String> p = new CourseFilter() {...}

1. is that correct?

2. And so to conclude, it seems that rule A and B DO hold, except for cases when RHS is an anonymous class...
In this case, perform 2 independent checks:
-first check the anonymous class implements the superclass/interface correctly,
-then check the assignment is correct.

Would you agree with these statements? (sorry for all the questions - super stressed   )

[Mike Simmons]

That's correct.  The exception isn't just for anonymous classes though - more generally, the compile doesn't figure out everything simultaneously; it figures things out in steps.  Because assignment operators are lowest in precedence, the compiler will figure out what the assignment operator does (and if any type conversion needs to happen) only after it figures out the type of the left side and the type of the right side.  Usually we don't need to isolate the individual steps when we think and talk about this, unless something complex is happening in one of the operands.

Put another way, rule A shouldn't mean, take out the generic and re-evaluate the whole expression without it.  It just means, pretend the generic isn't there, for purposes of deciding what the assignment operator does.  Your right-hand side was a Predicate<String> and the left was a Predicate, OK, so the resulting variable is a Predicate, OK.  But that does't force re-evaluation of the right hand side as a Predicate.

The other general rule is, when you mix raw types with generics, weird and confusing things happen, and so you should avoid mixing raw types with generics.  Or just avoid using raw types at all.