Java SE 7 Metamorphoses

Realmente, gerenciamento de processos vai ser a próxima (ou atual) onda do mercado. Vamos ver como a MS vai integrar isso nos seus produtos.

Quem fizer o melhor trabalho vai ter uma boa vantagem nos proximos anos.

marcelomartins wrote:Realmente, gerenciamento de processos vai ser a próxima (ou atual) onda do mercado. Vamos ver como a MS vai integrar isso nos seus produtos.

Quem fizer o melhor trabalho vai ter uma boa vantagem nos proximos anos.

Mas na minha ótica, mecanismos de BPM tem muito mais haver com Middleware e produtos do que com a plaforma de desenvolvimento - linguagem.

Kenobi wrote:

marcelomartins wrote:Realmente, gerenciamento de processos vai ser a próxima (ou atual) onda do mercado. Vamos ver como a MS vai integrar isso nos seus produtos.

Quem fizer o melhor trabalho vai ter uma boa vantagem nos proximos anos.

Mas na minha ótica, mecanismos de BPM tem muito mais haver com Middleware e produtos do que com a plaforma de desenvolvimento - linguagem.

Pois é, mas isso tem a ver com a maneira como o setor de marketing da microsoft vai trabalhar

Forum Spammer Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

Daniel Quirino Oliveira wrote:- JSR 274: uma amostra dos ventos da mudança: BeanShell, JavaScript, Groovy, sem falar que o povo do JRuby agora trabalha para a Sun. E tem gente que insiste em fechar os olhos para as mudanças.

O futuro são linguagens rodando na JVM para determinados fins específicos. Logo logo o JRuby, o Jython e outros forks terão mais usuários que os originais, e as linguagens sem plataforma perderão cada vez mais espaço.

Eu vejo em 10 anos que o mercado estará dividido em plataformas, a JVM e o .Net, com várias linguagens rodando em cada. O Ruby, o Python, etc, vão comer poeira. O dia que o Ruby rodar 100% a uma velocidade melhor na JVM não existirá motivo para usar o original, e ele estará morto.

Não sei se a Microsoft "viu isso", ou se mirou numa coisa e acertou outra. Mas me lembro do marketing na época do que o .Net foi lançado e parecia mais uma questão "escolha sua linguagem", e as principais eram C# e VB.Net, sendo o VB.Net só um skin do C# só que mais feio. Era de dar risada.

Vendo doutra forma, a proposta de linguagens dinâmicas em Java é interessante, pois usar Java para o core da aplicação e uma linguagem cuja produtividade seja maior para coisas externas é o que já fazemos de uma forma ou de outra.

Definitivamente existem coisas melhores que Ruby por aí, mas a Sun vai onde o hype está.

Daniel Quirino Oliveira wrote:
- JSR 277: gems para Java?

CPAN para Java? Outra coisa "nova".

Forum Spammer Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

Luca wrote:Uma perguntinha diabólica: quantos de nós ainda estaremos fiéis ao Java quando o JDK7 for lançado?

Eu uso Java desde o 1.0.2 e ainda não estou abandonando o barco. Mas ando meio assustado com o que vem por aí no .NET 3.0 e as outras possibilidades que existem como Ruby (e até mesmo algumas linguagens funcionais para usos específicos).

É necessário avaliar todos os fatores. Por exemplo, você vê alguém reclamando de "complexidade" no .Net? No entanto a Microsoft entulha o C# de features, deixando-o cada vez mais bloated e complexo.

Quero ver o que eles farão com as APIs. Como todos aqueles features novos ela ficará muito inconsistente. Será como em Perl, várias formas de se fazer a mesma coisa.

Sinceramente, isso é sinal de que eles não estão indo bem com esse negócio de .Net. Se eles estivessem confortavelmente dando uma surra no Java eles fariam que nem fizeram com o IE, ou seja, nada.

Quanto ao Ruby, Python e outras, elas serão assimiladas (pelos forks para a JVM e para o .Net) e os projetos originais ficarão comendo poeira. Esses projetos serão relegados ao gueto das linguagens de programação por questões óbvias.

Luca wrote:
O Linux e o Unix não estão crescendo como muitos sonharam e o Vista + .NET 3.0 darão uma razoável chacoalhada no mercado pró Microsoft, principalmente agora que ela distribui grátis o Visual Studio 2005 Express.

Não vejo como isso será diferente de nenhum release do Windows. De dois em dois anos ouvimos que o mundo como conhecemos irá acabar porque a Microsoft lançará a sua nova linha de produtos.

Luca wrote:
Se os paradigmas de programação nas grandes empresas mudarem para adoção em massa de Web Services, SOA e sistemas baseados em workflow, quem quiser sobreviver no mercado vai ter que aprender a interoperar com a Microsoft e ainda aprender a usar um monte de aplicativos novos como por exemplo ESBs (pelo menos nos primeiros anos) e repositórios de metadados (nada a ver com Maven).

Prefiro esperar para ver.

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1785 Offline

Paulo Silveira wrote:só nao gostei muito das propriedades... e detestarei se x.y = z for o mesmo que x.setY(z), pois perderemos legibilidade adoidados...

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

Forum Spammer Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

renato3110 wrote:

Paulo Silveira wrote:só nao gostei muito das propriedades... e detestarei se x.y = z for o mesmo que x.setY(z), pois perderemos legibilidade adoidados...

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

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.

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1785 Offline

Luca wrote: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...

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

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1785 Offline

Thiagosc wrote: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.

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

Forum Spammer Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

renato3110 wrote: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é...

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.

Forum Spammer Membro desde: 16/12/2004 17:09:19 Mensagens: 1785 Offline

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

Mais ou menos assim ehehhehe, enquanto nós só aqui com medo de criticar eheheheh

Thiagosc wrote:
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.

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.

chicocx wrote:

Thiagosc wrote:
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.

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.

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"

Forum Spammer Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

chicocx wrote: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.

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.

Forum Spammer Membro desde: 27/04/2006 21:01:27 Mensagens: 1134 Offline

renato3110 wrote: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...

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.

renato3110 wrote:
É 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..." Mais ou menos assim ehehhehe, enquanto nós só aqui com medo de criticar eheheheh

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

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