Generic return type upper bound-interface vs. class-zaskakująco poprawny kod

jest to rzeczywisty przykład z interfejsu API biblioteki innych firm, ale uproszczony.

skompilowany z Oracle JDK 8u72

Rozważ te dwie metody:

<X extends CharSequence> X getCharSequence() {
    return (X) "hello";
}

<X extends String> X getString() {
    return (X) "hello";
}

Obaj zgłaszają ostrzeżenie o "niekwalifikowanej obsadzie" - rozumiem dlaczego. To, co mnie dziwi, to dlaczego mogę zadzwonić

Integer x = getCharSequence();

I kompiluje? Kompilator powinien wiedzieć, że Integer nie implementuje CharSequence. Wezwanie do

Integer y = getString();

Daje błąd (jako oczekiwane)

incompatible types: inference variable X has incompatible upper bounds java.lang.Integer,java.lang.String

Czy ktoś może wyjaśnić, dlaczego takie zachowanie miałoby być uznane za słuszne? Jak to by się przydało?

Klient nie wie, że to wywołanie jest niebezpieczne - kod klienta kompiluje się bez ostrzeżenia. Dlaczego kompilacja nie ostrzega o tym / wydaje błąd?

Czym się różni od tego przykładu:

<X extends CharSequence> void doCharSequence(List<X> l) {
}

List<CharSequence> chsL = new ArrayList<>();
doCharSequence(chsL); // compiles

List<Integer> intL = new ArrayList<>();
doCharSequence(intL); // error

Próba przejścia List<Integer> daje błąd, zgodnie z oczekiwaniami:

method doCharSequence in class generic.GenericTest cannot be applied to given types;
  required: java.util.List<X>
  found: java.util.List<java.lang.Integer>
  reason: inference variable X has incompatible bounds
    equality constraints: java.lang.Integer
    upper bounds: java.lang.CharSequence

Jeśli zostanie to zgłoszone jako błąd, dlaczego nie?