[quote=fmeyer]O que nao seria diferente de ignorar as bobeiras ideologicas à enterprise que podem ser resolvidas de uma forma simples e direta de outra forma qualquer.
[/quote]
Mas que baboseiras? Tudo o que eles fazem é vender produtos, e compra quem quiser! Se você não gosta então não compre, ou se você não tem poder para decidir o que comprar então vá reclamar com quem toma essas decisões.
A única idelogia que parece estar dominando é a ideologia pragmática, o que por si só já é um paradoxo, hahahaha.
static import --> até e uma ideia interessante, mas nao vale o esforco da implementacao, alem de gerar confusao.
varargs --> a mesma coisa que usar um array, nao vi grande vantagem
autoboxing e o seu outro amiguinho --> poupam grande esforco, nos induzem cada vez mais a nao usar mais tipos primitivos.
Generics --> Um recurso interressante, mas vai demorar um pouco para os programadores se acostumarem a trabalhar com ele.
o novo for --> Iterator numca mais.
annotation -->excelente, mais nao acho que seja vantagem implantar em todas as partes do seu projeto, como por exemplo no hibernate… facilita muuuuito, evita xml, mas se um DBA alterar alguma propriedade do banco, como o nome de um atributo… ele pode nao ter autonomia suficiente para alterar tb na aplicacao. Agora ja no caso de um EJB por exemplo… a facilidade considerando as outras versoes e bem grande .
No contexto de programação, penso que ser pragmático é não ter que escrever 3 XMLs e 5 classes para um Hello World. É não ter que ficar escrevendo um monte de coisas desnecessárias para fazer o que você quer! É não ter que ler centenas de páginas para entender como a ferramenta ou a API funciona!
Convenhamos: muito coisa no mundo Java não é nem um pouco prático! Só agora vemos uma tendência de simplificar as coisas.
O que você falou no último post não tem sentido algum para mim.
[quote]# Doesn’t enforce type safety but still creates an illusion that it does.
Introduces a large number of syntaxes including a reuse of an existing keyword in a different context (extends) this is a problem that causes confusion and makes searches harder (although this is no where as bad as const in C++).
Compiles to a regular cast providing no advantage.[/quote]
Autoboxing/Generics:
[quote]List lst = new ArrayList;
lst.add(null);
int x = 1 + lst.get(0); //NPE![/quote]
Agora, eu não concordei com as críticas que ele fez às enums. Em casos onde eu preciso que constantes sejam passadas como parâmetros pros métodos, é bem mais interessante que enums sejam usadas, já que valores inválidos não compilariam.
E static imports são tão ruins quanto qualquer outra coisa static.
[quote=#@®®¡$]Pontos que eu concordo:
Sobre Generics:
[quote]# Doesn’t enforce type safety but still creates an illusion that it does.
Introduces a large number of syntaxes including a reuse of an existing keyword in a different context (extends) this is a problem that causes confusion and makes searches harder (although this is no where as bad as const in C++).
Compiles to a regular cast providing no advantage.[/quote][/quote]
Todos os novos features são em nível de compilação e não existem no código em tempo de execução. Tudo são gambiarras que no fim eram feitas pelo desenvolvedor e agora são feitas pelo compilador. Até aí nenhuma novidade, mas eu acho que um código genérico me diz muito mais do que um código não genérico. Mesmo que eu possa enrolar o compilador ou simplesmente não usar genéricos, acho que eles são muitos bons pra dar um pouco mais de “segurança” a linguagem.
x++
import static java.lang.String.format já virou praticamente obrigatório na classes que eu tenho que escrever log
[quote=Maurício Linhares][quote=#@®®¡$]Pontos que eu concordo:
Sobre Generics:
[quote]# Doesn’t enforce type safety but still creates an illusion that it does.
Introduces a large number of syntaxes including a reuse of an existing keyword in a different context (extends) this is a problem that causes confusion and makes searches harder (although this is no where as bad as const in C++).
Compiles to a regular cast providing no advantage.[/quote][/quote]
Todos os novos features são em nível de compilação e não existem no código em tempo de execução. Tudo são gambiarras que no fim eram feitas pelo desenvolvedor e agora são feitas pelo compilador. Até aí nenhuma novidade, mas eu acho que um código genérico me diz muito mais do que um código não genérico. Mesmo que eu possa enrolar o compilador ou simplesmente não usar genéricos, acho que eles são muitos bons pra dar um pouco mais de “segurança” a linguagem.[/quote]
Sim, mas as coisas ficam meio incômodas quando se usa junto com código que não usa Generics e este código adiciona o que não deve na sua Collection. Eu gostaria de uma segurançazinha extra em runtime, mesmo que tivesse que ser ativada na execução, como as assertions.
import static java.lang.String.format já virou praticamente obrigatório na classes que eu tenho que escrever log
[/quote]
Sei lá, não acho que o ganho de 7 caracteres seja uma justificativa para se tomar cuidado com a possibilidade de ter um método format(Object… o) na sua classe.
Claro, tudo tem exceções, mas eu já consigo até ver classes utilitárias sendo criadas e os métodos sendo importados por um import static br.com.foo.utils.Bar.* da vida. Claro, antes já havia o pessoal usando Bar.isso pra cá, e Bar.aquilo pra lá, e o problema já estava aí.
Fica parecendo o povo que cria interfaces só para guardar constantes.
Há mais ou menos 2 meses, eu e os desenvolvedores do meu projeto tivemos a ingrata surpresa de, depois de 4 meses desenvolvemdo em java 5, ficar sabendo que o sistema só poderia ser posto em produção no 1.4 (ia ser 1.3) porque o servidor de aplicação era de uma versão antiga e a nova sabe-se lá quando chega.
Refazer o código tem sido muito triste. Ter que comentar os Generics e Annotatios me parte o coração.
Tendo o desprazer dessa experiência, posso fazer uma lista igual a do Thingol só que com o que achei mais complicado desfazer do java 5 para 1.4 de volta:
[quote=thingol]Minha lista:
Generics +/- (muito acadêmico pro meu gosto)
Enums +/- (muito parecido demais com o Effective Java; podia ser mais bobo)
Static imports — realmente não funcionam bem
foreach +
autoboxing +/-
varargs +/- (eu em particular preferiria uma sintaxe de arrays “anônimos”)
annotations +
[/quote]
Generics +/- (é só comentar a aturar os warnings)
Enums ++ (esse é F***, muda o código dependente pra caramba)
Static imports ? (acho que não usamos)
foreach + (bem chatinho de refazer)
autoboxing +/- (muito código inútil apareceu de novo)
[quote=#@®®¡$][quote=Maurício Linhares] Todos os novos features são em nível de compilação e não existem no código em tempo de execução. Tudo são gambiarras que no fim eram feitas pelo desenvolvedor e agora são feitas pelo compilador. Até aí nenhuma novidade, mas eu acho que um código genérico me diz muito mais do que um código não genérico. Mesmo que eu possa enrolar o compilador ou simplesmente não usar genéricos, acho que eles são muitos bons pra dar um pouco mais de “segurança” a linguagem.[/quote]
Sim, mas as coisas ficam meio incômodas quando se usa junto com código que não usa Generics e este código adiciona o que não deve na sua Collection. Eu gostaria de uma segurançazinha extra em runtime, mesmo que tivesse que ser ativada na execução, como as assertions.
[/quote]
Eu também, já vi até algumas bizarrices que essa abordagem trouxe, mas acho que agente ganhou mais do que perdeu com isso.
Se você for um usuário Spring realmente é necessário escrever MUITO xml para fazer um Hello World. Mas não acho que essa crítica seja válida para o Java, é válida apenas para alguns usuários masoquistas de alguns frameworks.
Becos sem saída evolucionais são bons para aprendermos o que não fazer, nesse caso a não fazer o que o Spring faz.
" Eu conclui o seguinte em relação a genérics: Usar Generics é bom, pois o seu código fica mais limpinho sem aqueles casts todos. Já programar Generics é uma bosta… "
Infelizmente, melhor você dar uma olhada nas suas funcionalidades em algum bom livro. Se fosse bosta, não estaria lá.
Tem um moooonte de coisa em qualquer linguagem que eh uma bosta, mas que nao tem alternativas la muito melhores dadas as limitacoes que os criadores escolheram usar pra criar (ou adaptar) a linguagem.
Imports estaticos, java.util.Date e java.util.Calendar, por exemplo, foram e continuam sendo cagadas - mas na epoca, fez-se o melhor que pode dado o contexto - e esse contexto varia com o tempo e com a experiencia, e nada como discutir o que deu certo e o que deu errado pra entender como fazer melhor da proxima.
