With the code:

    class Test1<X extends CharSequence> { public X get() { return null; } }
    Test1<?> x = new Test1<>();
    x.get()

The temp variable and the reported expression type could be given the type CharSequence. With 8144903, it is Object.

Maurizio writes --

I think this fix is a stable point in the design space - the treatment of complex types is as simple as possible:

* captured vars are 'erased' using wildcard info
* intersection types are erased to Object

If you want to use the upper bound of a captured variable in a safe way you need to:

* check as to whether the bound is not recursive i.e. X extends Comparable<X>
* do something for intersection types, as declared bounds can be intersection types

This means TypePrinter will start doing subtyping tests and other similar stuff - which right now it's not the case.

While it might be worthwhile to explore that direction further, I believe that in the short term, the right thing to do is the conservative fix Shinya has put together. The fact that the regression test used to pass is more an accident than a feature; there are multiple variations of that test that won't work.