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 +

EDIT - por arrays anônimos, eu diria o seguinte:
No Java 5 o printf é assim:

System.out.printf ("Alô, %s! Você ganhou %.2f milhões na loteria!%n", "José", 2.14);

Acho que não seria tão incômodo assim escrever:

System.out.printf ("Alô, %s! Você ganhou %.2f milhões na loteria!%n", {"José", 2.14});

que indica que está sendo passado um array (o tipo depende da declaração do parâmetro do método).

O cara viaja. Na atual situação de Java, e até por causa do seu sucesso, a moda é “atirar pedras, depois arranje um pretexto, mas sempre atire pedras, e na dúvida atire pedras também”.

Se o Java NÃO tivesse mudado haveria gente chorando pelos cantos de que está muito defasado, que o .Net é 200 vezes melhor, etc, etc. Se o Java muda, então os mesmos chorarão pela “complexidade”.

O engraçado é que quando o .Net foi lançado já com muitas das features do Java 5 (com a exceção de Generics) haviam muitos “especialistas” alardeando a superioridade do .Net justamente por causa dessas coisas “cosméticas”. Porque não houve escândalo pela “complexidade” do .Net, e artigos de como o “simples” Java era tão melhor?

Bom, vamos ver quais das propostas para o Java 7 vão ser aceitas. Uma condição é, provavelmente, ter sido implementada antes no C#, para ver que problemas acaba causando.

• XML e SQL?
• Closures?
• Mais alguma coisa?

Eu acho essa história de XML e SQL muito estranha. Não vi utilidade ainda, se alguém viu, por favor me mostre :). Closures podem ser bem legais, dependendo de como for a implementação. Mas uma coisa que eu queria mesmo era uma maneira mais simples de se trabalhar com expressões regulares… Algo como Javascript ou Ruby, e não aquele negócio de PatternCompiler, Matcher, não sei o que, não sei o que lá.

Particularmente acho que:

1. Generics - detona. Evita diversos erros de ClassCastException…
2. Autoboxing - facilita as conversões.
3. Anotations - Loko.

Não acho generics acadêmico… embora seja um pouco complicadinho aplicar todas as suas funcionalidades (tipo <? extends P> em diversos lugares, etc)… facilitou bastante pra gente aqui.

Att.

Carlos Eduardo

Até o Fortran se atualiza de vez em quando… A última versão, para ter uma idéia, é de 2003.

The major additions are Object-Oriented Programming and Interoperability with C, but N1579 is 38 pages, and its table of contents is more than one page. Minor additions include procedure pointers, finalization of derived-type objects, parameterized derived types, pointer rank remapping (allows viewing one-dimensional arrays as higher-dimensional arrays), enumerations, the ASSOCIATE construct (similar to Pascal’s WITH), transferring an allocation (generalization of the frequently-requested reallocate capability), VOLATILE attribute, access to the command line and environment variables, standard named constants for “*” input and output units, access to message text for input/output and other errors, access to features of the IEEE floating-point arithmetic standard, longer names and statements, generalization of expressions for array dimensions and initial values, user-defined derived-type input/output, asynchronous input/output, and stream input/output–and this list is not exhaustive.

Annotations sem dúvida nenhuma foi uma adição incrivel a linguagem. Inquestionavel isso. Java está muito, muito melhor agora.

Já o resto, bom, também dava pra se virar bem se não existissem. Generics é bastante util, eu ainda não precisei usar o suporte a wildcards e union types, que é a parte cabeluda. Enum, foreach, varargs e auto-boxing ajudam a deixar o código mais legivel, vale a pena usar. Só static imports que não deu muito certo…

ceduardo.roque:

Particularmente acho que:

1. Generics - detona. Evita diversos erros de ClassCastException…

Generics não evita nenhum erro de ClassCastException, pois para pegar um erro desse vc tem que estar bêbado, ou seja, vc tem que colocar um gato numa lista de elefantes por engano.

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…

saoj:

ceduardo.roque:

Particularmente acho que:

1. Generics - detona. Evita diversos erros de ClassCastException…

Generics não evita nenhum erro de ClassCastException, pois para pegar um erro desse vc tem que estar bêbado, ou seja, vc tem que colocar um gato numa lista de elefantes por engano.

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…

Em C++ é uma beleza usar templates (que são mais ou menos o equivalente do Generics), principalmente aqueles prontos do STL, mas programar templates e entender os erros de compilação é que são elas.

Olá

Dei 5 estrelas mas eu não achava tão ruim aqueles casts porque achava fácil ler o código.

É claro que com generics alguns erros podem ser descobertos em tempo de compilação mas concordo que o Javadoc ficou um lixo.

Já li praticamente tudo que os bonzões escreveram sobre generics e ainda não me convenci de que valeu o trabalho de reescrever as APIs. Em resumo: acho bom mas sem nenhum wow.

Quanto às outras coisas até que gostei. O static import é bobeira porque sua utilidade é rara de ser aproveitada e ainda pode deixar o código menos legível.

O Java 5 saiu com algumas melhorias boas fora das mudanças na linguagem que acabaram esquecidas. O Java 6 também tem muitas novidades boas e não mexeu na linguagem.

[]s
Luca

Com exceção de deixar o código limpinho sem os casts, genéricas serve para muito pouco mesmo.

Se o trabalho que deu para implementar generics compensou isso eu não sei… Acredito que não…

Como hoje em dia está na moda linguagens diretas/pragmáticas/menos caracteres/qualquer adjetivo parecido com isso, foi um bom passo para o Java.

thingol:

Em C++ é uma beleza usar templates (que são mais ou menos o equivalente do Generics), principalmente aqueles prontos do STL, mas programar templates e entender os erros de compilação é que são elas.

Este ano eu tive que “recriar” uma bilbioteca (http://en.wikipedia.org/wiki/IBM_Open_Class) que a IBM nao da mais suporte no AIX 5.3, tive que trabalhar exclusivamente com templates para manter a compatibilidade com as milhoes de linhas de codigo que usavam esta biblioteca. e com certeza, os erros de compilacão em XLC ainda me fizeram repensar da proxima vez a pegar um trabalho com templates. Nao digo que foi ruim, mas é extremamente dificil de debugar, e explicar para os outros oque voce fez.

outra coisa,

ao menos a implementacao das colecoes genericas no java ficou bem menos esquisito do que a implementacao .net 2.0 que possui dois namespaces System.Collections e System.Collection.Generic para colecoes genericas e não genericas.

Eu nao considero uma moda e sim uma evolucão. como a propria lingua falada tende a evoluir de uma forma culta e complexa para uma forma prática e popular.

fmeyer:

outra coisa,

ao menos a implementacao das colecoes genericas no java ficou bem menos esquisito do que a implementacao .net 2.0 que possui dois namespaces System.Collections e System.Collection.Generic para colecoes genericas e não genericas.

Eles se deram ao luxo de fazer isso porque você sabe que a Microsoft está “pouco se lixando” com a compatibilidade com versões antigas. Como eles queriam fazer um Generics que fosse:

• mais rápido para tipos primitivos; e
• menos complicado que o Generics do Java,

então eles dispensaram o requisito da compatibilidade, e recriaram todas as Collections.

Agora mesmo um colega meu pegou um portal que foi feito com DotNetNuke e ele estava com o VS 2005 instalado. O problema é que o tal portal foi feito com VS 2003. O resultado é que ele teve de instalar também o VS 2003 porque um monte de coisas não funcionava

thingol:

Agora mesmo um colega meu pegou um portal que foi feito com DotNetNuke e ele estava com o VS 2005 instalado. O problema é que o tal portal foi feito com VS 2003. O resultado é que ele teve de instalar também o VS 2003 porque um monte de coisas não funcionava

Eu tive um problema quase parecido ao desenvolver uma biblioteca de pesquisa para um orgao estatico do governo que nao quis atualizar o framework, ( ta certo que esqueceram de especificar qual versao do framework eles usavam ) depois de rodar testar e homologar fui colocar em producao a tal biblioteca e esta simplismente nao funcionava e lancava milhares de erros.

e la se foram uns 30 minutos de ligacoes desesperadas.

Cara, estava lendo o theserverside e um cara veio com esse “pragmático” ao criticar um produto.

Essa palavra provavelmente é uma das mais abusadas/mal usadas para uma retórica tendenciosa contra o “mal enterprise”, ou seja, tudo o que não é opensource e coisa de hippie.

Vejamos pelo dicionário:

Eu frisei o significado que eu tomo por “pragmático”. Mas a questão é: pegar a palavra “pragmático” e usá-la como um ideal não é exatamente O OPOSTO do que a palavra significa?

Uma linguagem de programação NUNCA poderá ser pragmática!

Thiagosc:

Eu frisei o significado que eu tomo por “pragmático”. Mas a questão é: pegar a palavra “pragmático” e usá-la como um ideal não é exatamente O OPOSTO do que a palavra significa?

Uma linguagem de programação NUNCA poderá ser pragmática!

Acho que se voce prestar atencão um pouco abaixo tem uma definicao que se encaixa melhor.

Que sacrifica princípios ideológicos para a consecução de objetivos a curto prazo

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.

Thiagosc Não use este topico para dar uma de troll novamente por favor.

Olá

Há gente que acha que pelo menos os programadores podem ser pragmáticos.

[]s
Luca

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.

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.

Olá galera!!!

Bom voltando ao assunto inicial:

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 .

Thiago,

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.

deniswsrosa:

mas se um DBA alterar alguma propriedade do banco, como o nome de um atributo…

Bom, uma mudança na DDL do banco não é algo que o DBA decide fazer, sozinho, sem avisar ninguém e sem um bom motivo

Pontos que eu concordo:
Sobre Generics:

# 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.

Autoboxing/Generics:

<blockquote>List lst = new ArrayList;

lst.add(null);

int x = 1 + lst.get(0); //NPE!</blockquote>

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.

#@®®¡$:

Pontos que eu concordo:
Sobre Generics:

# 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.

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

Maurício Linhares:

#@®®¡$:

Pontos que eu concordo:
Sobre Generics:

# 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.

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.

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

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:

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 +
  

#@®®¡$:

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.

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.

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á.

Carlos

3a vez que vejo alguem fazer isso, não tem anda livre enste sentido? :?

Infelizmente, melhor você dar uma olhada nas suas funcionalidades em algum bom livro. Se fosse bosta, não estaria lá.

Só quiz falar que complica muito a linguagem, não sendo trivial…

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.