Artigo sobre Generics

tipos primitivos continuarão sendo oque já são.
autoboxing só ta vindo para ajudar a usá-los com classes que operam somente com objetos, como todas Collections

mas vai pode fazer o autounboxing

int i = new Integer(5);

Eba, mais pegadinhas pra galera que vai fazer certificacao!

Generics vai aumentar ainda mais o volume de besteiras do tipo:

String str = new String("string");

Já tou até imaginando…

Ué, louds, pq vc acha isso?

Pq alguem que usa:

String str = new String("string");

não utilizaria:

int numero = new Integer(1);

Me parece como um passo claro na evolução da linguagem fazer isso…
hehehehe
A não ser, obviamente, que alguem saiba de alguma justificativa válida e real para usar a primeira forma, com String, que não sejá pura sujeira.

louds, acho que, com certeza, o hotspot nao vai deixar aquele objeto integer ser criado. Ele vai perceber que ele soh vai ser usada pra tirar do box, entao ele vai soh usar como primitivo.

essa eh a aposta deles. que as coisas que iriam criar objetinhos demais, o hotspot saque e soh use primitivas.

mas a da String eh verdade, o pessoal da muito new e pouco intern.

bom
Se minha aplicação for para j2me, por exemplo, como fica ai?
A implementação de MIDP da Sun ate hoje usa um interpretador, sendo que já existem outras com JIT.
E se eu estiver usando a 1.4.1 no Itanium? Que não usa HotSpot.

O problema não é muito quanto a performance nesse caso, mas sim por piorar muito o código, que poderia ser simples.

Pra mim, a vantagem do autoboxing é caminhar para um futuro onde determinadas palavras reservadas caiam em desuso:

• int
• char
• byte
• boolean
• long
• float
• double

Se internamente ele usa objetos ou nao, to nem aih. O que me importa é a clareza do código.

[]s!!

E porque todos nós não jogamos fora o java agora e voltamos a usar SmallTalk então?

Ah, vai? C nao falou sério, neh??

Aliás, eu adoro SmallTalk. Digam o que quiserem.

Bom, eu gosto de saber com uma boa exatidão oque um pedaço de código faz, eliminando tipos básicos esse seria um dos problemas.

Outro problema é que a Sun não soube usar tudo que se aprendeu em C++ e linguagens anteriores sobre generalizar X fazer gambiarra p/ um caso particular. Sem falar do mal que conversões implicitas representam.

Infelizmente vou ter que concordar. A Sun nao aproveitou algumas coisas boas que já se sabia na época…

Mas vc lembra quando saiu o Java?? Em termos de linguagem, era uma beleza, vc nao podia fazer nenhuma merda que aparecesse só em tempo de execucao. Só que quase nao dava pra fazer nada de útil, só applets. O pessoal da Sun correu pra implementar “os outros quatro dedos da mao”, se vc me entende. Hoje, olhando pra trás, é fácil falar que eles nao souberam aproveitar a experiencia adquirida até entao. Mas na época, ninguém tinha muita certeza do que ia ser realmente importante hoje.

O .NET saiu bem depois do Java, com algumas diferencas importantes, por exemplo, no modo de ver excecoes. É uma aposta. Daqui a uns 6 anos, a gente vai ver se deu certo. E vai ter gente falando que eles nao souberam aproveitar os conceitos fundamentais aprendidos com C++ (a eterna), Java, etc.

Nao querendo pelamordedeus discutir Java vs dotinete.

Ah, mais uma coisa: deixa pra lá essa historia de ler código e saber o que ele faz. Todo código bom (aquele que vc nao precisa mexer) vai estar bem documentado e vc nao vai precisar lê-lo. Código ruim, bom, pra que lê-lo, se está ruim??

Foi na Wired ou na ComputerWorld que saiu um artigo falando exatamente sobre esse lance co .net tomando conta.

Afinal, já se vão 3 anos desde que a MS introduziu o .net e o java ainda não é 1 tecnologia falida. E se isso fosse realmente acontecer, acredito que já teria dado tempo.

A MS, assim como a Sun cometeram, na minha humilde opinião, alguns erros, uns pequenos, outros graves; que no final só significa que a longevidade de ambas tecnologias vai ser um pouco menor.