Dúvida questão generics

Você não pode fazer um cast para S. S vai ser apagado, por causa do type erasure.

Além disso, pense no que aconteceria se S for uma String. Você tentaria fazer um cast de StringBuilder para String, o que é conceitualmente um erro.

Agora, o enunciado está errado. Isso aí só gera um warning, não um erro.
E funciona tranquilamente na execução, mesmo com o erro citado acima.

O erro só vai ocorrer quando um método do retorno for usado. Aí ele vai acusar que não pode fazer cast de String para StringBuilder. Faça o teste!

ViniGodoy:

Agora, o enunciado está errado. Isso aí só gera um warning, não um erro.
E funciona tranquilamente na execução, mesmo com o erro citado acima.

O erro só vai ocorrer quando um método do retorno for usado. Aí ele vai acusar que não pode fazer cast de String para StringBuilder. Faça o teste!

Então, pode haver casos que em tempo de execução (run) dê erros correto? Se for, o enunciado está correto, pois ele pede que seja inserido sem erros de compilação e execução. Correto?

bl.rafael:

ViniGodoy:

Agora, o enunciado está errado. Isso aí só gera um warning, não um erro.
E funciona tranquilamente na execução, mesmo com o erro citado acima.

O erro só vai ocorrer quando um método do retorno for usado. Aí ele vai acusar que não pode fazer cast de String para StringBuilder. Faça o teste!

Então, pode haver casos que em tempo de execução (run) dê erros correto? Se for, o enunciado está correto, pois ele pede que seja inserido sem erros de compilação e execução. Correto?

Na verdade o “erro em execução” que poderia ocorrer seria um ClassCastException. Por exemplo:

public class Foo<E> {
    public E getFoo() { return (E) "aaa"; }
}

public class Bar {
    public static void main(String[] args) {
        Integer h = new Foo<Integer>().getFoo();
    }
}

O negócio é que “compile and run without error” não é o termo mais adequado. Seria mais correto “compile without error and runs without throwing runtime exceptions”.

O que eu não gosto dos enunciados, de maneira geral, é que são terrívelmente escritos. Sinceramente, Foo e Boo não são nomes de classes. E frases ambíguas como essa são terríveis.

Mas o enunciado está certo. Levando em conta todas as possibilidades de execução, podem haver erros em runtime.

ViniGodoy:

O que eu não gosto dos enunciados, de maneira geral, é que são terrívelmente escritos. Sinceramente, Foo e Boo não são nomes de classes. E frases ambíguas como essa são terríveis.

Mas o enunciado está certo. Levando em conta todas as possibilidades de execução, podem haver erros em runtime.

Que Foo, Boo, Bar, Moof e afins não são nomes de classes todos deveriam saber. O problema é que esses são os nomes de classes mais comuns que aparecem no exame real (o objetivo é mostrar classes cuja a estrutura seja irreconhecível, e por isso esses nomes pouco significativos), e é por isso que são frequentes nos simulados também.

O foda são os imbecis que pensam que esses nomes são normais e começam a implementar sistemas reais que tenham classes chamadas Foo. Se pelo menos chamassem a classe de Pog ao invés de Foo ficava mais claro o que está sendo feito.

Em criptografia você normalmente chama as partes relacionadas de Alice, Beto, Carlos (ou seja, A, B, C)…

Tem gente que acha que “Foo” é alguma coisa orientada a objeto - bitola pouca é bobagem, mas já ouvi falar tal asneira. (E é por isso que odeio a sigla POO porque ela, em inglês, quer dizer “caca”).