De fato, Class<Formatter> fclass só pode receber um argumento do tipo Class<Formatter>, não Class<? extends Formatter>.
Não é à toa que o pessoal do .NET inventou (no C# 3.0) a sintaxe var:
// se fosse em C#:
var fclass = tag.getFormatterClass();
onde "var" é uma abreviatura para o tipo correto, que neste caso é "Class <? extends Formatter>".
Esse compilador do JDev está bem bugadinho, hein? Se ele usar o próprio javac, será que não é possível trocar a versão? Compilei o código com o JDK 5.0 e 6.0 e funciona direitinho.
interface Formatter {
}
class Cep implements Formatter {
}
class BugGenerics {
public Class <? extends Formatter> getFormatterClass() {
return Cep.class;
}
public static void main(String[] args) throws Exception {
Class<? extends Formatter> fclass = new BugGenerics().getFormatterClass();
Formatter fmt = fclass.newInstance();
}
}
É, realmente. Ainda segundo o livro da Kathy Sierra [quote]There’s a very simple rule here?the type of the variable declaration must match the type you pass to the actual object type. If you declare List foo then whatever you assign to the foo reference MUST be of the generic type . Not a subtype of . Not a supertype of .Just .
[/quote]
Agora, esse erro no JDev é realmente estranho. Qual exception ele lança?
Conclusão: o compilador do JDeveloper (que deve ser o próprio Javac) e o editor do JDev não falam a mesma língua (se a Oracle tentasse rodar aquela suite de testes do Javac, para comprovar a compatibilidade com o javac, provavelmente não passaria.
Isso deve ser porque a equipe da Oracle que cuida da JVM da Oracle, e que tem acesso à suite de testes da Sun, não deve se falar com a equipe do JDeveloper.)
Alguém sabe se a Oracle ainda teima em ter sua própria versão da JVM ou eles desistiram?
Para evitar esses problemas, o Eclipse criou seu próprio compilador, para poder ser usado no editor também, e a equipe do NetBeans solicitou “gentilmente” à equipe do Javac que houvesse uma maneira de poder acessá-lo diretamente, para evitar esse esforço dobrado.