Java SE 7 Metamorphoses

Assuntos Gerais Notícias
#21

[quote=renato3110][quote=Paulo Silveira]só nao gostei muito das propriedades… e detestarei se x.y = z for o mesmo que x.setY(z), pois perderemos legibilidade adoidados…
[/quote]

Eu gostei, pessoalmente não acho que há perda de legibilidade, apenas o setter é mais “verboso”. É bem claro que no teu caso tanto faz a forma, o que estamos fazendo é atrinuir um valor à y, a diferença é que hoje em dia você sabe se algum código está sendo executado ou não, mas não acho que seja tão importante assim. Talvez você fale daquela coisa de mensagens entre objetos, mas não acho que isso “mate” o conceito…

Eu acho que os programadores Java já fizeram tantos getters/setters que acabam achando properties algo meio bizarro, quando o que eu acho bizarro é digitar código à tôa (IMHO)…
[/quote]

E qual a diferença entre “x.y = z” e y como atributo público? Em Java não é obrigatório fazer todos os campos como privados, portanto não seria mais fácil fazê-lo público para assim evitar os “terríveis setters”? O resultado não seria o mesmo?

Não entendi a sua crítica.

#22

[quote=Luca]Olá
Em tempo: minha intenção não foi sabotar a excelente compilação do Bush e sair do tópico com uma discussão .NET x Java. Fui o primeiro a dar 5 estrelas para o post dele.

Apenas quiz chamar a atenção de que enquanto o Java lida com os detalhes da linguagem no JDK, os caras do JEE podem colocar tudo a perder se não reagirem a tempo. Vejamos o que chamo de reagir…
[/quote]

Um lance que tem é que o .NET é feito por uma empresa, enquanto que o Java é feito por um consórcio. Ou seja, em Java, como no software livre, parece não existir muito uma “visão comercial”, no sentido positivo de não atrofiar os músculos, de ouvir o que os usuários pensam e querem, o programador do dia-a-dia, não apenas o carinha lá que é doutorado em num sei o quê… Eu acho que a Microsoft ouve mais os seus usuários…

#23

[quote=Thiagosc]E qual a diferença entre “x.y = z” e y como atributo público? Em Java não é obrigatório fazer todos os campos como privados, portanto não seria mais fácil fazê-lo público para assim evitar os “terríveis setters”? O resultado não seria o mesmo?

Não entendi a sua crítica.
[/quote]

Entendi o que você quer dizer. Mas se você precisar colocar uma lógica associada à atribuição do campo? Você tem que usar um getter/setter. E todos os frameworks que se baseiam em getters/setters? Além disso, se você tiver alguns campos apenas com lógica de validação, vai ficar meio inconsistente você pegar um objeto, e quando setar uma propriedade você ver que algumas é com set, outras com atribuição de campo…Além disso, como fazer um campo exposto ser read/write-only?

O properties não significa a eliminação de getters/setters, mas sim a transparência dos mesmos. Se você tem um campo simples, ok, não há getters/setters. Mas se você tem que fazer alguma validação, é só adicionar o getter/setter, quando você fizer z = x.y ou x.y = z eles serão automaticamente acionados. Mas a maioria dos campos não têm validação né…

Por falar nisso, a página sobre properties que o Bush mostrou tem uma implementação da idéia com o Mustang, e parece que o cara é brasileiro! Ou algo do tipo…

#24

[quote=renato3110]Entendi o que você quer dizer. Mas se você precisar colocar uma lógica associada à atribuição do campo? Você tem que usar um getter/setter. E todos os frameworks que se baseiam em getters/setters? Além disso, se você tiver alguns campos apenas com lógica de validação, vai ficar meio inconsistente você pegar um objeto, e quando setar uma propriedade você ver que algumas é com set, outras com atribuição de campo…Além disso, como fazer um campo exposto ser read/write-only?

O properties não significa a eliminação de getters/setters, mas sim a transparência dos mesmos. Se você tem um campo simples, ok, não há getters/setters. Mas se você tem que fazer alguma validação, é só adicionar o getter/setter, quando você fizer z = x.y ou x.y = z eles serão automaticamente acionados. Mas a maioria dos campos não têm validação né…
[/quote]

Mas aí eu acho ruim. Um método deve ser chamado como um método, uma operação de atribuição como uma operação de atribuição. Você na verdade estaria chamando um método escondido do desenvolvedor, apenas para economizar algumas tecladas.

Aí é uma questão de filosofia, explícito é melhor que implícito e o código que está escrito é o que é feito sem mais nem menos.

#25

Realmente é uma questão de filosofia, eu já pensei nesse lance de ah, mas aí eu vou tá chamando código implicitamente sem perceber, como se fosse um medo…mas no final das contas esse medo pra mim é medo de nada…

Não há problema em um método rodar por trás, quem entender o conceito de properties vai saber que potencialmente, em toda a atribuição de campo, há um get/set rodando… Olha o link, o primeiro exemplo dele já começa mostrando uma economia de 80%! de código com properties…

O lance do framework Swing também vi, mas eles não podiam embutir isso no Swing, ou seja, um novo Swing? Essa história de framework vai ficar que nem aquele lance de mais uma opção pra se fazer as coisas…

É engraçado como nas JSRs, eles próprios metem o pau nas features atuais do Java: “hoje em dia, é simplesmente ridículo programar em Swing… Javadoc é uma tecnologia de 10 anos de idade, totalmente ultrapassada… assim como os arquivos JAR, que datam da época do ENIAC…” :smiley: Mais ou menos assim ehehhehe, enquanto nós só aqui com medo de criticar eheheheh :smiley:

#26

Se você der uma olhada no JSTL, JSF e outras frameworks web verá que as propriedades já são tratadas assim e sem problema algum.

#27

[quote=chicocx][quote=Thiagosc]
Mas aí eu acho ruim. Um método deve ser chamado como um método, uma operação de atribuição como uma operação de atribuição. Você na verdade estaria chamando um método escondido do desenvolvedor, apenas para economizar algumas tecladas.
[/quote]

Se você der uma olhada no JSTL, JSF e outras frameworks web verá que as propriedades já são tratadas assim e sem problema algum.[/quote]

Pior, se você ver qualquer outra coisa que não seja o Java já é assim.

** Licensa poêtica, eu quis dizer “a maioria das outras coisas”

#28

JSTL é uma linguagem à parte do Java, e foi criada para evitar o uso de Java no JSP.

Faz sentido evitar Java dentro do Java? Acho que não.

#29

[quote=renato3110]Realmente é uma questão de filosofia, eu já pensei nesse lance de ah, mas aí eu vou tá chamando código implicitamente sem perceber, como se fosse um medo…mas no final das contas esse medo pra mim é medo de nada…

Não há problema em um método rodar por trás, quem entender o conceito de properties vai saber que potencialmente, em toda a atribuição de campo, há um get/set rodando… Olha o link, o primeiro exemplo dele já começa mostrando uma economia de 80%! de código com properties…[/quote]

Eu acho essa questão de setters exagerada. Se a sua aplicação tem 80% do código com getters e setters é sinal que ela não é mais do que um monte de Javabeans.

Em quantas aplicações você já trabalhou que eram 80% do código assim? Eu nunca, talvez algum Hello World da vida.

[quote=renato3110]
É engraçado como nas JSRs, eles próprios metem o pau nas features atuais do Java: “hoje em dia, é simplesmente ridículo programar em Swing… Javadoc é uma tecnologia de 10 anos de idade, totalmente ultrapassada… assim como os arquivos JAR, que datam da época do ENIAC…” :smiley: Mais ou menos assim ehehhehe, enquanto nós só aqui com medo de criticar eheheheh :D[/quote]

E como isso afeta o que realmente é? Quer dizer que se fulano esculhamba com o JARs é sinal de que devemos entrar na onda?

Eu sou contra a “mudança pela mudança”, sou a favor da “mudança pela melhoria das ferramentas com que trabalhamos”.

#30

[quote=renato3110]
Um lance que tem é que o .NET é feito por uma empresa, enquanto que o Java é feito por um consórcio. Ou seja, em Java, como no software livre, parece não existir muito uma “visão comercial”, no sentido positivo de não atrofiar os músculos, de ouvir o que os usuários pensam e querem, o programador do dia-a-dia, não apenas o carinha lá que é doutorado em num sei o quê… Eu acho que a Microsoft ouve mais os seus usuários…[/quote]

Eu acho justamente o contrário :stuck_out_tongue:
O JCP ouve bem os usuários, principalmente pelo fato de que os usuários podem fazer parte do JCP se eles tiverem boas idéias.

#31

[quote=renato3110]
Um lance que tem é que o .NET é feito por uma empresa, enquanto que o Java é feito por um consórcio. Ou seja, em Java, como no software livre, parece não existir muito uma “visão comercial”, no sentido positivo de não atrofiar os músculos, de ouvir o que os usuários pensam e querem, o programador do dia-a-dia, não apenas o carinha lá que é doutorado em num sei o quê… Eu acho que a Microsoft ouve mais os seus usuários…[/quote]

Acho que isso não é um ponto a favor… a JCP garante o investimento constante das EMPRESAS em Java… pois ninguem investe 50 bilhoes de dolares sendo que amanha alguem muda de ideia e troca tudo (alguem lembra de .net 1.1 pra 2.0 ? )

Acho que metade das funcionalidades do C# em sua versao 2.0 são bizarras , e as que vem no 3.0 são totalmente doidas… complexas e deixam o codigo terrivelmente complexo e poluido…

#32

Tudo que eu coloquei foi comentado como candidato ao Java SE 7.
Na compilação tem-se os proponentes e participantes das referências (com suas implementações de referência, drafts, propostas, arquivos, apresentações multimídias, blogs, grupos e listas de discussões, artigos, etc).
*Exceção: Property support, Partial Classes são candidatos ao Java SE 7, mas os artigos foram feitos “ad hoc”.

No mais, este ano ainda vai ter uma renca de JSRs propostas.

[ ]´s

#33

Exemplifique, eu até acho que meia duzia de coisas meio estranhas para mim, mas em grande maioria eu acredito que são coisas úteis que facilitam e deixam o código mais limpo, por exemplo:

  1. Partial Class
    Aqui a microsoft fala: Nos damos suporte a IDEs! Partial classes são utilizadas aonde a IDE gera metada da classe e o usuário gera a outra metade. Exemplo no Netbeans e em outras IDEs aonde tem métodos inlegiveis e que você não pode nem tocar. Ou em outros casos onde “metade” da sua classe vai para um XML com as configurações das telas e eventos. Você têm na sua metade só o que é “inteligente”. E nada de impede de vizualiar a outra metade burra. Isso acontece hoje com a maioria das IDEs Java mas no modo cambalacho.

  2. Linq
    Isso é fantástico. Imagine você poder criar a sua própria DSL integrada ao seu código e com todas as funcionalidades de uma IDE (autocomplete, verificação de erros e etc). No java a unica coisa feita nesse sentido foi justo com XML, aonde na minha visão, é menos proveitosso.
    Imagine a JBoss criando uma DSL Linq para o HQL e você usando HQL sem precisar ser string. Com autocomplete, validação e etc.

Eu poderia escrever outras coisas aqui, mas não meu intuito começar uma guerra Tecnologia x Tecnologia, só gostaria de pedir exemplos quando fala-se esse tipo de coisa. Só para ter certeza que não é simplemente “eu gosto do Java, e não é feito da mesma maneira que no Java”.

#34

[quote=microfilo]Eu acho justamente o contrário :stuck_out_tongue:
O JCP ouve bem os usuários, principalmente pelo fato de que os usuários podem fazer parte do JCP se eles tiverem boas idéias.[/quote]

O problema é que o JCP é muuuuito lento e acadêmico. Demora muito para especificar uma coisa e como tem muita gente dando pitaco nem sempre sai coisa boa.

Normalmente as coisas boas saem quando eles chupam a idea de um framework já existente no mercado (vide EJB3) e mesmo assim ainda conseguem estragar um pouquinho.

O que falta no JCP é um esquema menos democrático. Aonde um, no máximo dois, são responsaveis pelas decisões. O papel dos outros é simplemente opinar.

#35

[quote=juzepeleteiro]1) Partial Class
Aqui a microsoft fala: Nos damos suporte a IDEs! Partial classes são utilizadas aonde a IDE gera metada da classe e o usuário gera a outra metade. Exemplo no Netbeans e em outras IDEs aonde tem métodos inlegiveis e que você não pode nem tocar. Ou em outros casos onde “metade” da sua classe vai para um XML com as configurações das telas e eventos. Você têm na sua metade só o que é “inteligente”. E nada de impede de vizualiar a outra metade burra. Isso acontece hoje com a maioria das IDEs Java mas no modo cambalacho.[/quote]

Algumas perguntas:

  • Essa feature deveria ser algum gancho interno para aplicações como IDEs fazerem uso? O que li na internet foi justamente a possibilidade do desenvolvedor usá-lo, o que é extremamente não-inteligente.

  • E o que impede o Swing de guardar dados num arquivo separado, como o Delphi fazia?

Realmente não vejo utilidade nisso, todas as “vantagens” possíveis podem ser feitas sem essa feature (um arquivo separado para dados do IDE) e só resta a complexidade. Se o problema é referenciar o dito arquivo com algum Annotation, então crie-se uma convenção para o nome e a localização do mesmo para se evitar problemas.

Mais uma vez pergunto, onde estão os desenvolvedores reclamando da complexidade do C#? Ou ninguém está usando, ou a quantidade de desenvolvedores Java no mundo os excede em muito e não podemos ouvi-los, ouvimos apenas a “complexidade do Java”.

[quote=juzepeleteiro]2) Linq
Isso é fantástico. Imagine você poder criar a sua própria DSL integrada ao seu código e com todas as funcionalidades de uma IDE (autocomplete, verificação de erros e etc). No java a unica coisa feita nesse sentido foi justo com XML, aonde na minha visão, é menos proveitosso.
Imagine a JBoss criando uma DSL Linq para o HQL e você usando HQL sem precisar ser string. Com autocomplete, validação e etc.
[/quote]

Complexidade 10 x 0 usuários.

Tenho a impressão que quem acredita que DSLs são a salvação da lavoura nunca ouviu falar de Lisp e de macros. Preferiria muito mais ter uma implementação de Common Lisp rodando na JVM e eu mesmo criar quaisquer abstrações que desejasse.

O problema é que nem Java e nem C# são Lisp.

#36

[size=9]juzepeleteiro wrote:[/size]

Eu também sou desta opnião vou pra onde o mercado(maior remuneração e maior possibilidade de trabalho) me levar, nos dias atuais eu acho que não podemos ficar teclando numa tecla só diante de várias tecnologias e tendências.

[size=9]chun wrote:[/size]

Compatibilidade entre versões é essencial, desde que para manter esta compatibilidade não seja necessário retardar a evolução e facilidades da linguagem. Para mim e tudo uma questão de evolução/mercado, a empresa tem todo direito de não migrar para versões mais recentes mas esta correndo um sério risco em sair do mercado e quando chegar o SOA, o que vai acontecer?! Sei que da o maior trabalho para migrar de uma técnologia pra outra, mas tem que pensar que tem outras empresas que estão ai, correndo atrás…:roll:

Sou a favor das inovações e mudanças desde que elas sejam para o bem estar coletivo…
Pois o Mundo é redondo, não é?!
:wink:

#37

Já usou google? Já ouviu falar da famosa implementação de LISP que roda na JVM chamada Armed Bear Common Lisp? (http://armedbear.org/abcl.html).

As macros do lisp tem seus problemas, mas no geral provem uma enorme vantagem para os desenvolvedores. Leia o livro do Paul Grahan sobre lisp para ver como elas são usadas no mundo real. Por sinal, qual a SUA experiência com linguagens que não Java?

#38

[quote=Thiagosc][quote=renato3110]
É engraçado como nas JSRs, eles próprios metem o pau nas features atuais do Java: “hoje em dia, é simplesmente ridículo programar em Swing… Javadoc é uma tecnologia de 10 anos de idade, totalmente ultrapassada… assim como os arquivos JAR, que datam da época do ENIAC…” :smiley: Mais ou menos assim ehehhehe, enquanto nós só aqui com medo de criticar eheheheh :D[/quote]

E como isso afeta o que realmente é? Quer dizer que se fulano esculhamba com o JARs é sinal de que devemos entrar na onda?

Eu sou contra a “mudança pela mudança”, sou a favor da “mudança pela melhoria das ferramentas com que trabalhamos”.
[/quote]

Ué, mas o que é, e o que não é, é relativo. Eu tô faalndo justamente disso, de entrar na onda. Se você chegasse aqui há um tempo atrás e saísse falando que arquivos JAR são ridículos, ia ver quanta gente ia te apedrejar…Aí eu acho engraçado ler a própria JSR praticamente dizendo isso…Outro exemplo é se eu falar aqui que desenhar telas pelo código é coisa de doido… quase ninguém vai concordar… é engraçado …

[quote=microfilo][quote=renato3110]
Um lance que tem é que o .NET é feito por uma empresa, enquanto que o Java é feito por um consórcio. Ou seja, em Java, como no software livre, parece não existir muito uma “visão comercial”, no sentido positivo de não atrofiar os músculos, de ouvir o que os usuários pensam e querem, o programador do dia-a-dia, não apenas o carinha lá que é doutorado em num sei o quê… Eu acho que a Microsoft ouve mais os seus usuários…[/quote]

Eu acho justamente o contrário :stuck_out_tongue:
O JCP ouve bem os usuários, principalmente pelo fato de que os usuários podem fazer parte do JCP se eles tiverem boas idéias.[/quote]

É meio paradoxo isso… mas sei lá, quantos programadores do dia-a-dia sabem que o JCP existe?

Ué, então por que ele não faz? :smiley:

#39

[quote=louds]Já usou google? Já ouviu falar da famosa implementação de LISP que roda na JVM chamada Armed Bear Common Lisp? (http://armedbear.org/abcl.html).

As macros do lisp tem seus problemas, mas no geral provem uma enorme vantagem para os desenvolvedores. Leia o livro do Paul Grahan sobre lisp para ver como elas são usadas no mundo real. Por sinal, qual a SUA experiência com linguagens que não Java?[/quote]

Ok, você conhece Lisp e como as macros funcionam em Lisp? “Tem seus problemas” é um tanto quanto genérico. Macros acabam com a repetição de código, todos esses getters/setters entre outras coisas seriam facilmente removíveis.

Apenas acontece, como eu disse, que nem Java e nem C# são Lisp. Isso significa que entulhar essas linguagens de features duvidosas apenas as farão mais complexas do que o necessário.

Sobre a implementação, sim, e existem várias linguagens para a JVM. Nunca testei nenhuma da JVM, uso o sbcl, mas existe um enorme diferença entre um projeto versão 0.0.9 e um pronto para produção. Portanto o Google somente não ajuda.

Isso sem mencioar o fato de que o último release é de outubro de 2005. Alguém se arrisca a usá-lo em produção? Eu prefiro manter meu emprego.

#40

[quote=Thiagosc]
Ok, você conhece Lisp e como as macros funcionam em Lisp? “Tem seus problemas” é um tanto quanto genérico. Macros acabam com a repetição de código, todos esses getters/setters entre outras coisas seriam facilmente removíveis.[/quote]

Cara, eu conheço pouco do sistema de macros do lisp, conheço melhor o mecanismo de macros higiênicas do scheme e um pouco das macros do Dylan (essas mais teóricamente que na prática).

Agora queria saber de você o que você vê de bom, de preferência com exemplos, das macros do lisp e por que isso não seria aplicavel ao Java. Foi isso que eu entendi do que você falou, que macros seriam ruim em Java, me perdoe se entendi errado.

Existem pesquisas em adicionar suporte à macros higiênicas no Java, aos moldes do Dylan, que é usando quotations e syntax case, basicamente. Dylan é uma linguagem muito mais próxima de Java que scheme ou lisp, então dá para fazer um paralelo razoável, já que não é uma tonelada de parênteses a todo lado.

Pessoalment eu preferiria um mecanismo de macros que todas essa modificações que estão propondo, pois properties e lambas podem ser emulados via macros com um pouco de esforço.