Quem acha que Generics é a coisa mais idiota do Java 5.0?

Junta uma implementação que é mais gambiarra que as soluções já existentes, uma justificativa que acabou virando uma mentira. Mais corner-cases que casos comuns. Sintaxe para usos mais avançados lembra templates do c++, para quem não conhece, leia confusa, complexa e pouco intuitiva.

Toda a porcaria que Generics são se deve ao fato da Sun querer manter compatibilidade com versões anteriores e não alterar o bytecode gerado. No final das contas mudaram o formato e não temos como programar com generics para java 1.4.

Erasure gera uma quantidade de corner-cases tão grande que eu não vejo vantagens em usar alêm daquilo que a biblioteca prove.

Generics são uma bomba?

Quanto aos generics, nao fui a fundo. De momento achei particularmente meio inutil o lance de static imports.

Marcio Kuchma

generics são elgais, agora os programadores C++ não tem o que falar. Ah, ele é só açúcar sintático? Não rola reflection direito?

É,

_o/

[]s

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

É sempre assim, quando as pessoas têm medo de mexer em alguma coisa.
Em vez de tomar uma decisão corajosa, como o pessoal do .NET :lol!: (a parte de generics foi construída "em paralelo" à infraestrutura já existente, então temos List, que é igual à nossa velha conhecida java.util.List, e GenericList<>, que é igual à nova java.util.List<>, se não me engano), fizeram uma solução que é basicamente para "autocasting". A única coisa interessante é a parte do "foreach".
Por exemplo, percorrer os pares chave-valor retornados por java.lang.System.getenv() em J2SE 5.0 é agora bastante fácil:

A parte mais chata é descobrir a declaração certa da variável "env" no código acima, devido aos "generics". O programa acima, sem o "foreach", é meio complicado (meio é modo de dizer)

A declaração de "it' é meio complicada (meio é modo de dizer), só para evitar o cast em Map.Entry<String,String> entry = it.next();, que nos velhos tempos seria apenas Map.Entry entry = (Map.Entry) it.next();

pcalcado wrote:generics são elgais, agora os programadores C++ não tem o que falar. Ah, ele é só açúcar sintático? Não rola reflection direito?
[]s

Não rola reflection, não rola coisas básicas que eu não acreditei quando soube que não teria.

Fiquei muito puto quando soube que isso não rola.
Se tivessemos todo poder dos templates do c++ sem meta-programação com suporte total via reflection, teriamos uma ferramenta muito poderosa e não 1 ninho de vespas como vai ser...

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

A parte de "metadata" parece que vai ser de alguma valia. Nisso eles não tiveram de mexer em bytecodes, mas a JVM precisa ser atualizada para entender direito essa parte de metadata. Mas isso foi mais ou menos copiado do .NET (só que o conceito do .NET foi um pouco ampliado, já que temos vários tipos de "anotações", não só de "tempo de execução" como é o caso do .NET).

Acredito que Generics é uma solução no vazio, uma perda de tempo. Tentaram solucionar um problema inexistente, pelo menos para mim. Poluiram a sintaxe da linguagem a troco de quê?

Se alguém conseguir me explicar as reais vantagens disso ficarei bastante contente.

Seria economizar casting ??? Acho que não, pois o bytecode precisa ser compatível com as VMs anteriores.

Seria evitar ClassCastExceptions dentro de uma collection ??? Acho que não pois se o cara quer uma lista de um objeto só, então use um array, ou extenda a lista para só aceitar esse tipo de objeto.

Deve haver alguma situação muito particular onde isso é vantajoso, mas não justifica alterar a parada toda só por causa dessa situação incomum.

Whatever...

saoj wrote:
Seria economizar casting ??? Acho que não, pois o bytecode precisa ser compatível com as VMs anteriores.

O velho açúcar sintático, economiza pro programador...

Alan Perlis wrote:
Syntactic sugar causes cancer of the semi-colon.

[]s

pcalcado wrote:O velho açúcar sintático, economiza pro programador...

Hehehe. Entendi, economiza digitação para o programador, depois que algum condenado digitou toda a maluquice dos Generics na API.

A economia que eu me referia era o tempo que a VM gasta para fazer um cast de um objeto, que eu acho é bem pequeno.

Com Generics o casting seria desnecessário SE O BYTE CODE NÃO ESTIVESSE SENDO GERADO COM O CASTING PARA SER COMPATÍVEL COM AS OUTRAS VMS !!!!

Não é isso que acontece ????

Olá

Há muitos meses atrás detonei os generics achando que complicam a leitura do código em troca de pouca vantagem. Só estou reafirmando a mesma opinião aqui porque sei que o louds que abriu este tópico estudou muito o uso de generics e não levantou esta lebre atoa.

Particularmente não me vejo em uma equipe que use generics nos próximos 2 ou 3 anos que é o tempo mínimo para alguém simplificar seu uso para o programador normal. Até lá já estaremos com Java 6.0 com outras coisas realmente úteis.

[]s
Luca

A especificação de Generics diz que ela não deveria diminuir a performance do código em mais que 5%.

louds wrote:A especificação de Generics diz que ela não deveria diminuir a performance do código em mais que 5%.

Então diminui ao invés de aumentar !!!??? Putz, que ótimo!

Essa parada que eu falei do casting faz sentido, louds? Ou seja, no bytecode o Generics some e entra o casting ?

Não, com Generics os castings somente apenas do código.
O bytecode gerado é quase igual ao gerado hoje para um código sem generics.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

Como disse é um "automatic casting".
Uma coisa que achava muito legal em Java, no começo, é que você lia o código e sabia exatamente o que estava acontecendo (diferentemente do C++, que pode criar um monte de objetos e destruí-los sem você saber direito o que está acontecendo, até que uns 5 anos mais tarde, você consegue saber todas as regras de escopo, criação e destruição de objetos, operadores e outras coisas mais cabeludas).
Agora está ficando igual ao C++. Por exemplo, isto aqui:

é equivalente em bytecodes ao seguinte código (basta ver o que o seu compilador gerou com javap, já que o jad não está funcionando direito ainda com o J2SE 5.0):

ou seja, tem um cast "automático" na linha onde pergunto o sobrenome do "josé". Grande coisa. Mas isso pode dar algum problema porque casts são sempre casts, codificados ou não (e sempre lançam ClassCastException...)
Outra coisa "automática" que é uma droga é o "static import". Quando criarem uma versão do Checkstyle ou PMD que suporte o J2SE 5.0 vou sugerir que todos os "static import" sejam tratados como "warnings".
Mas para não dizer que tudo que é automático é uma droga, o "foreach" é muito legal, e os "annotations" (metadata) também são muito legais.

Os cast automáticos não seriam problema se Generics fosse typesafe mesmo.

Notícias, artigos e o maior fórum brasileiro sobre Java