Arquivo da tag: java

Entenda os MVCs e os frameworks Action e Component Based

É muito comum encontrar desenvolvedores que aprendem componentes do JSF como o Primefaces e o Richfaces e gostariam de usá-las em seus projetos que utilizam frameworks web como o Spring MVC, Struts e VRaptor, porém, isso não é possível. Por que? Entenda os diferentes funcionamentos do MVC, aprenda como funcionam os frameworks e tire para sempre essa e outras dúvidas!

Um @Controller do SpringMVC

Quando trabalhamos com o SpringMVC, tratamos as requisições enviadas pelos usuários dentro de classes conhecidas como Controller. É uma classe simples, anotada com @Controller onde implementamos métodos que tratam a requisição para uma determinada URL, indicada através da anotação @RequestMapping.

@Controller
public class ProdutosController {
   @RequestMapping("adicionaProduto")
   public void adiciona(Produto p, HttpServletRequest req) {
      // pega o produto recebido no request e grava no banco de dados
   }
}

Quando a requisição é submetida para o endereço adicionaProduto e envia os parâmetros adequados para preencher o objeto Produto, ele é gravado no banco. Porém, precisamos devolver uma resposta para o usuário, que deverá conter o nome do produto adicionado, então podemos disponibilizar um atributo ao JSP através do request que recebemos no nosso método.

@RequestMapping("adicionaProduto")
public void adiciona(Produto p, HttpServletRequest req) {
   // pega o produto recebido no request e grava no banco de dados
   req.setAttribute("nome", p.getNome());
}

Então logo após a execução da ação, indicamos para o SpringMVC que o produto-adicionado.jspdeve ser mostrado. Para isso, basta fazermos nosso método retornar uma String com o nome do JSP.

@RequestMapping("adicionaProduto")
public String adiciona(Produto p) {
   // pega o produto recebido no request e grava no banco de dados
   req.setAttribute("nome", p.getNome());
   return "produto-adicionado";
}

Dessa forma, após a execução, o JSP será exibido para o usuário.

<h2>Produto ${nome} adicionado com sucesso</h2>

Onde está o MVC aí?

O mais importante nisso tudo, é notar que existe uma separação clara entre as responsabilidades no tratamento da requisição.

Quando um usuário submete uma requisição para o endereçohttp://localhost:8080/projeto/adicionaProduto, o SpringMVC a recebe e descobre, de alguma maneira, qual é o @Controller e qual método deve ser responsável por tratá-la. Nesse caso, o SpringMVC está fazendo o papel do Front Controller, que delega a responsabilidade para umController secundário, no caso a classe ProdutosController e o método adiciona. Chamamos o responsável por esse trabalho de Controlador.

Os passos do controlador

O próximo passo é a execução das regras de negócio, que podem envolver a execução da persistência das informações, validações e outras tarefas que dizem respeito aos requisitos funcionais da aplicação. Chamamos as classes que fazem esse trabalho de Modelo.

@Controller invoca o Modelo para realizar as regras de negócio

Após a execução do Modelo e de todas as as regras de negócio, o JSP contendo a resposta adequada deve ser exibido para o usuário. Nesse ponto, temos as regras de visualização implementadas, como por exemplo, exibir as informações em vermelho, dada alguma característica. Essas regras ficam todas centralizadas no JSP, que nesse caso, faz um papel que chamamos de Visão, ou seja, é o responsável pelo que o usuário irá visualizar como resultado.

@Controller indica qual visão será devolvida para o usuário

Juntando tudo o que vimos, temos o MVC – Modelo, Visão e Controlador, cujo objetivo é separar as responsabilidades da aplicação, fazendo com que tenhamos um código mais fácil de ser mantido.

Os frameworks Action Based e o MVC Push

….

Saiba mais em: http://blog.caelum.com.br/entenda-os-mvcs-e-os-frameworks-action-e-component-based/

Fonte: Adriano Almeida / Caelum

Nova API JSON padrão para Java será desenvolvida

Uma nova interface Java para processamento de dados no formato JSON foi aprovada pela Java Community Process (JCP) como uma Java Specification Request (JSR).

Com 10 votos a favor e 6 abstenções, o comitê executivo votou a favor do JSR 353, que, primeiramente, tem como objetivo ser a base para o desenvolvimento padronizado para futuras APIs JSON e vai permitir que aplicativos sejam menores e mais portáveis por não terem o pacote existente nas bibliotecas JSON.

A proposta planeja capacitar a produção e o consumo do texto JSON, em um estilo semelhante ao da API StAX usada para XML. Além disso, ela está focada na produção de um modelo de objeto e de uma API para texto JSON, em um estilo semelhante ao da API DOM para XML.

O pedido aponta especificamente que ligar o texto JSON a objetos Java, e vice-versa, não é a meta da especificação. Os desenvolvedores afirmaram que pretendem integrar o JSR 353 no Java EE 7, assim como oferecer uma variante independente para o for Java SE 6 e superior.

O SouJava, grupo de usuários brasileiros, votou a favor do JSR e comentou favoravelmente a respeito do trabalho da especificação, liderado por Jitendra Kotamraju, que, segundo eles, já demonstrou sua habilidade em envolver desenvolvedores a partir da comunidade mais ampla. A IBM também se manifestou e afirmou que seu voto a favor do JSR foi exclusivamente baseado nos méritos técnicos do JSR 353.

Com informações de The H

Fonte: IMasters

Canonical vai remover Java do sistema de usuários

A Canonical anunciou na semana passada que vai remover sistematicamente o Java do Ubuntu, deixando espaço para alternativas livres. A decisão tem base nos problemas de segurança encontrados nos pacotes JDK do Java, usados também em navegadores. Várias das vulnerabilidades foram descobertas em outubro e até hoje permanecem sem solução, oferecendo risco aos usuários. Dessa forma a Canonical achou mais fácil desabilitar o plugin e cortar o mal pela raíz.

As primeiras versões do Ubuntu a serem afetadas serão a 10.04 LTS, 10.10 e 11.04. A ideia envolve substituir os pacotes disponíveis atualmente no repositório de Parceiros com pacotes vazios. Assim, ao fazer a atualização, o próprio Ubuntu removeria todos os arquivos do sistema.

A Canonical já está alertando aos usuários para que migrem para OpenJDK e desinstalem o JDK da Oracle (caso eles o tenham baixado e instalado manualmente), ou eles poderão “experimentar falhas após a atualização dos pacotes”.

Marc Deslauriers, da Canonical, disse que eles podiam remover os pacotes dos repositórios e deixar os pacotes inseguros nos sistemas dos usuários, ou remover tanto dos repositórios, quanto dos sistemas, de forma remota. “Não há uma forma perfeita de lidar com isso”, ele disse, “mas infelizmente essa é melhor maneira de lidar com o problema e garantir que nossos usuários permaneçam seguros, ao custo de quebrar algumas instalações”.

Portanto, se você ainda não usa o OpenJDK ou o icedtea, é bom começar a se preparar, ou muito em breve terá problemas para acessar páginas que tenham código Java.

Por Paulo Graveheart

Fonte: IMasters

Java 8: O estado atual do lambda

Brian Goetz publicou uma atualização do “estado do lambda“, dando informações da situação do plano de adicionar lambdas na linguagem Java, que também pode ser acompanhado pela JSR 335 e pela proposta de melhoria do Java número 126.

O plano para trazer os lambdas para a linguagem Java cobre tanto as sintaxes para funções anônimas, como planos para estender o conjunto de classes Java existentes (tal como as de Collections), com métodos que aceitem lambdas também. O objetivo é adicionar funções como map e filter, para que coleções possam ser processadas de forma mais funcional.

De modo a fornecer este comportamento nas interfaces existentes (e não somente nas classes básicas do Java), um novo tipo de método foi adicionado às interfaces, chamado método default (antes chamado método defender).

Isto efetivamente permite que interfaces tenham implementações de métodos, de forma bem parecida com as traits do Scala ou classes abstratas do Java. Quando um método é invocado através de uma referência de interface, o compilador inicialmente delega a chamada do método para uma instância; mas se nenhuma implementação do método for encontrada, o método default declarado na interface é invocado.

Diferentemente do que acontecia em versões anteriores da especificação, em vez de se definir um apontador para um método estático existente, a nova especificação permite métodos (mas não atributos) de interface com corpos válidos, identificados com a palavra-chave default. O seguinte exemplo adiciona o método skip() a todos os iterators:

interface Iterator<E> {
boolean hasNext();
E next();
void remove();
 
void skip(int i) default {
for (; i > 0 && hasNext(); i--) next();
}
}

Como a mudança efetivamente adiciona a implementação de herança múltipla à linguagem Java, no caso de colisões (quando o mesmo método default é herdado por dois caminhos separados), o método precisa ser redefinido na classe. Ou então um dos métodos default deve ser explicitamente chamado através do construtor: new Iterator.super.skip().

Outra recente mudança é a sugestão de alterar a sintaxe das referências a métodos, de Person#compare, inspirada no JavaDoc, para uma sintaxe mais inspirada no C++ como Person::compare. Qualquer que seja a sintaxe adotada, as referências de métodos fornecem um atalho tipado para um método que recebe um lambda.

Embora as expressões atuais do lambda não tenham sofrido muitas alterações, algumas partes da sintaxe e da terminologia vêm sendo revisadas. Por exemplo, a decisão anterior era de usar =>, adotado em C# e Scala, como sintaxe para introduzir uma expressão lambda; agora a sintaxe foi alterada para ->. Assim, uma função que retorna a negação dela mesma, pode ser escrita como int a -> -a. (Se o tipo de a puder ser inferido, ele é usado como alternativa; no caso de expressões em que o compilador não consegue identificar o tipo como byte, short, int ou long, será preciso fazer a distinção explicitamente ).

Outra mudança em terminologia ocorre para classes como Runnable e Action. Estas são interfaces com um único método abstrato, antes chamadas tipos SAM (Single Abstract Method). Para estimular o seu uso mais amplo no Java, agora são chamadas de interfaces funcionais.

A mudança visa encorajar o uso desses tipos como sendo conversíveis para um tipo mais geral, partindo de uma referência a um método. Dessa forma, onde um código Java existente tem métodos que esperam instâncias de Comparator, pode-se passar agora uma expressão lambda ou um handle do método com a mesma assinatura do método compareTo() do Comparator. Embora tecnicamente o Comparator tenha dois métodos abstratos (compareTo() e equals()), ainda é visto como uma interface funcional, pois equals() já é disponibilizado em Object.

Embora as funções tipadas tenham sido consideradas (estão disponíveis em um rascunho inicial da especificação), foram rejeitadas, pelo menos por agora. Isso porque apagar uma função tipada causa problemas na versão atual da JVM. Embora não esteja descartada a inclusão das funções tipadas no futuro, há a expectativa de que interfaces funcionais baseadas em tipos sejam mais úteis em Java do que um novo tipo funcional.

Os lambdas continuam tendo uma vantagem na qual o tipo do argumento pode ser inferido sem ter que se definir explicitamente o tipo (a menos que haja necessidade de distingui-lo, como mencionado). Lambdas podem também ser recursivos e capturar estados de escopos externos (lambdas que capturam escopos externos são conhecidos como closures). A captura acontece somente para variáveis com modificador final. No entanto, a adoção de um “final efetivo”, significa que o final pode ser inferido em muitos locais e não precisa ser explicitamente mencionado.

A adição de lambdas à linguagem Java, juntamente com referências a métodos, irá reduzir significativamente a quantidade de código repetitivo necessário para operações comuns. Por exemplo, para ordenar um array de strings diferenciando maiúsculas e minúsculas, poderá ser escrito:

Arrays.sort(names, String::compareToIgnoreCase)

Juntamente com os métodos default, que permitem que interfaces cresçam (como os traits do Scala) sem afetar os códigos existentes, essas mudanças deixarão o código Java muito mais conciso. Não teremos um completo híbrido objeto-funcional, mas veremos um crescimento no número de bibliotecas com estilo funcional a partir do JDK8.

O código compilado com lambdas e métodos default não rodará em versões anteriores ao JDK8, mas será possível compilá-lo com versões mais antigas do JDK e usá-lo de maneira funcional. O processo será parecido com o que foi utilizado para trazer os tipos genéricos gradualmente para a linguagem Java.

Fonte: Alex Blewitt , traduzido por Rafael Sakurai/InfoQ

Conhecendo o F#

Como você sabe, existem algumas linguagens OOP por aí. Você provavelmente conhece VB.Net, C# e Java, mas eu vou falar de uma relativamente nova.

Gostaria de falar um pouco sobre F#.

Similar ao C# e ao VB.Net, o F# também é direcionado para o Framework .Net e também é orientado a objeto.

A principal diferença no F# não é sua sintaxe única, mas sim o novo ponto de vista e o estado de espírito que traz para a programação orientada a objeto.

O F# usa inferência de tipos – o que significa que o programador não precisa se preocupar com a declaração de tipo e pode apenas utilizar a palavra reservada “let” (que é similar a “var”). A declaração do tipo de dados será deduzida pelo compilador durante a compilação (o F# também permite a declaração explícita de tipos de dados).

Depois dessa pequena introdução ao F# (bem pequena), gostaria de começar a parte prática. E este artigo será sobre Listas no F#.

Vamos fazer um pequeno experimento:

Crie uma lista de ints no C#

List<int> newList = new List<int>();

Adicione os seguintes valores a essa lista:

newList.Add(5);
newList.Add(2);
newList.Add(-3);
newList.Add(1);

Agora por favor tente classificá-la usando valor absoluto.

Você provavelmente descobrirá que se você tentou fazer isso, você usou a funcionalidade da programação.

No F#, é quase o mesmo, e fica o mais fácil possível, uma vez que você chega neste ponto:

[5; 2; -3; 1] |> List.sortBy(fun intElem -> abs intElem)

Vamos testar nossas habilidades no C# mais uma vez mapeando a lista de ints (cada número será aumentado em 3).

Mais uma vez, a maioria de vocês que se saiu bem usando LINQ ou outra programação funcional que o C# permite, é assim que funcional no F#:

[5; 2; -3; 1] |> List.map(fun x-> x * x * x)

Outro teste para o poder do nosso C# (ou Java) será tentar filtrar essa lista para ints que retornam 0 quando divididas por 2. No F#, é fácil assim:

[5; 2; -3; 1] |> List.filter(fun x -> x % 2 = 0)

Esses foram apenas alguns exemplos sobre o F# e sua usabilidade. Espero que ajude você a compreender a sintaxe, e mais importante – que ajude você a pensar em programação funcional.

Falando nisso, como podemos esquecer o imortal primeiro programa: “Hello World!” ?

printfn "Hello World!"

Texto original disponível em http://www.devaffair.com/2011/01/first-steps-in-f-sharp.html

Fonte: IMasters

Conhecendo o F#

Como você sabe, existem algumas linguagens OOP por aí. Você provavelmente conhece VB.Net, C# e Java, mas eu vou falar de uma relativamente nova.

Gostaria de falar um pouco sobre F#.

Similar ao C# e ao VB.Net, o F# também é direcionado para o Framework .Net e também é orientado a objeto.

A principal diferença no F# não é sua sintaxe única, mas sim o novo ponto de vista e o estado de espírito que traz para a programação orientada a objeto.

O F# usa inferência de tipos – o que significa que o programador não precisa se preocupar com a declaração de tipo e pode apenas utilizar a palavra reservada “let” (que é similar a “var”). A declaração do tipo de dados será deduzida pelo compilador durante a compilação (o F# também permite a declaração explícita de tipos de dados).

Depois dessa pequena introdução ao F# (bem pequena), gostaria de começar a parte prática. E este artigo será sobre Listas no F#.

Vamos fazer um pequeno experimento:

Crie uma lista de ints no C#

List<int> newList = new List<int>();

Adicione os seguintes valores a essa lista:

newList.Add(5);
newList.Add(2);
newList.Add(-3);
newList.Add(1);

Agora por favor tente classificá-la usando valor absoluto.

Você provavelmente descobrirá que se você tentou fazer isso, você usou a funcionalidade da programação.

No F#, é quase o mesmo, e fica o mais fácil possível, uma vez que você chega neste ponto:

[5; 2; -3; 1] |> List.sortBy(fun intElem -> abs intElem)

Vamos testar nossas habilidades no C# mais uma vez mapeando a lista de ints (cada número será aumentado em 3).

Mais uma vez, a maioria de vocês que se saiu bem usando LINQ ou outra programação funcional que o C# permite, é assim que funcional no F#:

[5; 2; -3; 1] |> List.map(fun x-> x * x * x)

Outro teste para o poder do nosso C# (ou Java) será tentar filtrar essa lista para ints que retornam 0 quando divididas por 2. No F#, é fácil assim:

[5; 2; -3; 1] |> List.filter(fun x -> x % 2 = 0)

Esses foram apenas alguns exemplos sobre o F# e sua usabilidade. Espero que ajude você a compreender a sintaxe, e mais importante – que ajude você a pensar em programação funcional.

Falando nisso, como podemos esquecer o imortal primeiro programa: “Hello World!” ?

printfn "Hello World!"

Texto original disponível em http://www.devaffair.com/2011/01/first-steps-in-f-sharp.html

Fonte: IMasters

IcedTea, Harmony, IKVM e mais: altos e baixos do Java Open Source

Este artigo traz um panorama de projetos open source relacionados com o coração da plataforma Java, e em que tem havido extremos de altos e baixos. Em outubro, o IcedTea liberou sua versão 2.0, baseada no OpenJDK 7, que já está disponível como o Java 7 oficial do Fedora e do Ubuntu Linux; em novembro a Apache anunciou que o Harmony estava sendo rebaixado para o “sótão” da Fundação. São dois exemplos (e dois extremos) de projetos trazendo novidades que poderão afetar o futuro da tecnologia Java, mesmo sem o apoio de gigantes como Oracle e IBM.

IcedTea

Quando a Sun liberou em 2007 os fontes da sua JVM e sua biblioteca de classes, criando o projeto OpenJDK, atual implementação de referência do Java 7, o resultado não era imediatamente usável pela comunidade open source, pois alguns componentes licenciados de terceiros não puderam ser abertos naquele momento. Exemplos de APIs que não foram incluídas no código inicial do OpenJDK são as de gerência de fontes tipográficas e de interação com dispositivos de som. Sem falar de complementos indispensáveis para algumas aplicações, como o plugin web para Applets e o Java Web Start, que embora sejam parte do produto da Sun e Oracle há tempos, cobrem funcionalidades não-padronizadas como parte do Java SE.

Para remediar esses problemas, a comunidade open source criou, com patrocínio da Red Hat, o projeto IcedTea. O objetivo era substituir os componentes proprietários necessários para compilação e execução do OpenJDK, pelos equivalentes em outros projetos open source, especialmente o projeto GNU Classpath.

Na verdade, já havia conversas entre membros importantes da comunidade open source e da Sun bem antes do lançamento do OpenJDK, e não foi acidente a opção da Sun pela licença GPL, em vez das licenças usadas no Glassfish e no extinto Open Solaris. O objetivo era permitir a mistura de código com o ecossistema do GNU Classpath, baseado na GPL.

Já há alguns anos, as distribuições do Linux incluem binários certificados do IcedTea, mas que são distribuídos usando o nome OpenJDK como parte de um acordo com a Sun para acesso ao TCK, o kit de testes de compatibilidade do Java.

Algumas distribuições ofereciam como alternativa o Java proprietário da Sun, empacotado nos repositórios “não-livres”, usando a licença DLJ (Operating System Distribution License for Java). Mas a DLJ foi descontinuada pela Oracle com a liberação do Java 7, não apenas para o novo Java mas também para as versões anteriores. Por isso o IcedTea se tornou o único Java certificado a ser fornecido como parte dos sistemas Fedora, Ubuntu e Debian, além de se tornar também o preferencial para uso em distribuições comerciais com RHEL e SuSE.

O escopo do projeto IcedTea aumentou desde a sua criação. Ele implementou melhorias sobre o OpenJDK, para melhor compatibilidade com o Linux, por exemplo o suporte ao PulseAudio para multimídia; e evoluiu para uso de JVMs alternativas, como a JamVM, entrando no lugar do HotSpot do OpenJDK original.

Ampliando o alcance do OpenJDK

A maior contribuição do IcedTea para o OpenJDK provavelmente foi os projetos Zero e Shark. O Zero é um interpretador genérico de alta performance, que torna o OpenJDK viável em várias plataformas embarcadas, em que o custo de memória e bateria de um compilador JIT seria proibitivo.

Já o Shark utiliza a infraestrutura do LLVM para criar um compilador JIT portável para múltiplas arquiteturas de CPU, evitando a necessidade de se escrever um novo JIT para cada arquitetura de processador. Graças a estes projetos o OpenJDK vem se tornando a implementação do Java preferencial em algumas CPUs populares em plataformas voltadas para a computação embarcadas, como ARM e MIPS.

Note que o IcedTea não é um fork do OpenJDK. Alguns dos seus contribuidores estão no Community Board do OpenJDK e vários dos patches do projeto migraram para o OpenJDK e se tornaram parte do Java 7 oficial.

Outra contribuição importante do IcedTea é um processo de compilação mais simples para o OpenJDK, reduzindo a barreira de entrada para potenciais contribuidores. O projeto OpenJDK não fornece binários para nenhuma plataforma, somente fontes. O JDK fornecido pela Oracle à partir dos fontes do OpenJDK usa uma licença proprietária. Mas, graças ao processo simplificado do IcedTea hoje é possível baixar, sob uma licença open source, binários para Windows no site do Open SCG, que é o mesmo grupo responsável pelo porte nativo do PostgreSQL para Windows.

A certificação do Java SE é realizada sobre binários, não sobre fontes, e os binários do IcedTea inclusos no Ubuntu, Fedora e derivados (como RHEL e CentOS) são certificados desde 2009. Mas os binários do OpenJDK 7/IcedTea 2 inclusos nas distribuições do Linux não são certificados ainda, e nem os fornecidos pelo OpenSCG para Windows. Ambas as comunidades estão trabalhando no processo, e estão em busca de patrocinadores.

Ainda há espaço para outras JVMs open source?

A criação do projeto OpenJDK diminuiu o incentivo a continuidade de vários projetos de JVMs open source. O SableVM foi uma das vítimas. O desenvolvimento do GNU Classpath, que fornecia a biblioteca de classes do Java SE para a maioria destes projetos, ficou congelado no Java SE 5, e o venerável Kaffe apenas recentemente voltou a ter atividade, sendo transferido para o Github.

Poderia ser argumentado que não há mais necessidade de outros projetos de JVMs open source, uma vez que a Sun abriu sua implementação, e ainda mais agora que a Oracle oficializou o OpenJDK como a implementação de referência (RI) para o Java 7. A competição trazida por estes projetos foi benéfica porque estimulou a evolução e a abertura do JDK pela Sun, mas qual seu papel no futuro do Java?

Na época o Classpath estava chegando perto do 100% do Java SE 5 e se tornaria certificável. Com dois Javas open source plenamente funcionais (GCJ+Classpath e Apache Harmony) ficaria complicado manter restrições ao TCK do Java SE, e mais importante, o fluxo de caixa originado pelo licensiamento do JDK da Sun para fabricantes de plataformas móveis e embarcadas. A criação do OpenJDK sob licença GPL permitiu unir esforços à comunidade open source, sem abrir o TCK para projetos externos.

Por outro lado, sem projetos open source independentes, deixa-se de explorar alternativas de design para a JVM, que poderiam atender a nichos específicos ou se tornarem importantes em plataformas futuras. O fato de smartphones e tablets atuais em sua maioria ignorarem a plataforma Java SE (e também a Java ME) mostra que essas alternativas podem estar fazendo falta.

Por exemplo, o GCJ, que é parte da suite de compiladores GCC, tem a opção de gerar código nativo (que não necessita de uma JVM para executar). Era uma opção interessante para aplicações desktop e sistemas embarcados, tanto que foi utilizado pelo RHEL e pela comunidade Fedora para suportar o Eclipse e o Tomcat, antes da criação do OpenJDK. Sem falar na ampla cobertura de arquiteturas de CPU e SOs do GCC, muito superior à suportada pelo Java “oficial” na época.

As releases recentes do GCC continuam suportando o GCJ, e ele continua sendo incluído nas principais distribuições do Linux; mas, infelizmente não parece haver planos para atualizar seu suporte à linguagem Java, nem para completar o GNU Classpath ou atualizá-lo para além do Java 5.

JVMs alternativas ao OpenJDK

O OpenJDK, no entanto, não parece ter diminuído o ritmo do JikesRVM, que tem o diferencial de ser escrito quase que inteiramente em Java. Infelizmente ele não tem a pretenção de ser uma JVM para “uso real”, seu objetivo é ser uma plataforma de testes para novos algoritmos internos à JVM para projetos acadêmicos.

Dois dos projetos baseados no GNU Claspath, o JamVM e o Cacao continuam vivos. Eles colaboram com o projeto IcedTea e hoje podem utilizar a biblioteca de classes do OpenJDK em lugar do GNU Classpath, voltando assim a acompanhar a evolução da plataforma oficial. Apesar de os seus releases mais recentes terem mais de um ano, existe grande atividade nos repositórios de código do JamVM e do Cacao, e espera-se para breve novos releases que finalmente atualizarão suas respectivas JVMs para compatibilidade com as novas versões do Java.

Ambos o JamVM e o Cacao são focados em plataformas embarcadas, explorando diferentes designs para componentes da JVM, como o coletor de lixo, o interpretador de bytecodes e o compilador JIT. A comunidade do JamVM afirma, por exemplo, que é possível gerar um executável da sua JVM ocupando menos de 100 Kb.


Java no .NET

Outro projeto de JVM open source que continua vivo e pode ser interessante para alguns nichos é o IKVM, que roda dentro do CLR do .NET ou do Mono, e permite convivência “sem costuras” entre código escrito em Java e código escrito em C#, VB.Net ou outras linguagens que rodam sob o CLR.

O IKVM também permite empacotar aplicações Java como assemblies nativas do .NET. O projeto ganhou certa popularidade entre desenvolvedores que gostariam de continuar tendo acesso a bibliotecas Java em um projeto .NET. É também o projeto mais atualizado em relação aos padrões do Java, pois já oferece um release candidate com suporte ao Java 7.

Com o fim do Harmony, como fica o Android?

A DalvikVM, que é a base das aplicações Android, é baseada na biblioteca de classes do Java SE fornecida como parte do Apache Harmony. Originalmente este projeto tinha apoio da IBM, que contribuiu com a maior parte do código para a biblioteca de classes, mas quando a IBM decidiu focar seus esforços no OpenJDK, o Harmony ficou “órfão”. O projeto Harmony foi oficialmente descontinuado pela Apache Software Foundation em novembro deste ano. Ao contrário do que muitos esperavam, o Google não assumiu o projeto, mantendo o desenvolvimento do Dalvik como um fork separado, provavelmente devido ao processo aberto pela Oracle por violação de patentes.

O Dalvik não é exatamente uma JVM, pois roda seu próprio bytecode, e usa uma arquitetura interna bem diferente da usada no OpenJDK, embora semelhante ao JamVM e ao CacaoVM. O desenvolvimento das aplicações para o Dalvik é feito na linguagem Java, e os bytecodes Java são convertidos em bytecodes Dalvik. Está disponível apenas um subconjunto da API do Java SE, embora maior do que o incluso no Java ME, mas o Dalvilk não traz nada do Java oficial para celulares, sendo incompatível com MIDP ou CDC. Recursos que seriam parte do Java ME são fornecidos por APIs proprietárias para o Android, ou por acesso a serviços do Google.

A omissão do Google quanto ao Harmony dá margem a dúvidas sobre qual será o futuro do “Java” no Android:

  • O Google vai continuar evoluindo o Dalvik usando ideias do Java, de modo similar feito pela Microsoft com o .NET?
  • Ou será o HTML 5 quem poderá provocar um futuro abandono do DalvikVM e Java no Android?

Qualquer que seja o futuro do Dalvilk, ele representa uma linha que poderia ter sido incorporada ao Java oficial e que garantiria a popularidade do Java na computação móvel. A disputa entre Google e Oracle não atende aos interesses da comunidade Java, e a recente ênfase no HTML 5 mostra bem como o mercado ainda carece de uma solução para desenvolvimento interoperável entre smartphones e tablets de diferentes fornecedores.

Serviços nativos do Linux

O exemplo do Dalvik mostra que, apesar da necessidade de funcionalidades independentes de plataforma, há também necessidade de se incorporar suporte a recursos nativos. O Java 7 já foi uma evolução nessa direção, com a nova API de filesystem do NIO2 e se pode argumentar que o Eclipse deve grande parte do seu sucesso ao toolkit gráfico SWT, também baseado no acesso a recursos nativos de Windows, Unix e Mac.

Novamente vemos que a comunidade open source traz novidades neste sentido, dentro do ramo da computação embarcada. Por exemplo, o BUG System e o OpenEmbedded fazem uso de APIs Java para acesso ao desktop Gnome e o D-Bus – efetivamente colocando o Java em pé de igualdade com o código nativo, no acesso aos recursos do SO e Desktop do Linux.

Em vez de criar todo um “universo paralelo”, como feito pelo Android, estes projetos buscam maximizar a utilidade de recursos já conhecidos dos desenvolvedores em plataformas embarcadas, e abrem espaço para a plataforma Java como “linguagem de sistema” para o Linux, viabilizando o desenvolvimento de aplicações de gerência de hardware sem recorrer diretamente a código nativo.

Conclusões

Podemos ver que, apesar do foco de grandes empresas no projeto OpenJDK, ainda há vários outros projetos open source com potencial de contribuir para a evolução da plataforma, especialmente em nichos ainda negligenciados pela plataforma oficial, como o de dispositivos embarcados. Vale a pena acompanhar o amadurecimento destes projetos, pois de um deles pode sair o diferencial competitivo para os produtos da sua empresa, ou surgirem evoluções importantes para a plataforma oficial do Java.

Fonte: Fernando Lozano/InfoQ

Google App Engine 1.6.0: Graduação oficial e mais novidades

Após três anos e meio do lançamento da plataforma, o Google AppEngine deixa de ser um produto ‘preview’ e passa a ser completamente suportado pelo Google. O crescimento da plataforma neste tempo foi excepcional. Estatísticas atuais dão conta de mais de 100 bilhões de requisições por mês, 300 mil aplicações em execução e acima de 100 mil novos desenvolvedores adicionados mensalmente. Ficam claros, portanto, o sucesso e a necessidade de investimentos a longo prazo no GAE.

Com a nova versão 1.6.0, oficialmente será adotado o novo modelo de cobrança, conforme anunciado em maio; também foram publicados os documentos termos de serviço e política de uso, e há uma SLA de 99.95%.

E a nova versão traz um conjunto de novas funcionalidades:

  • Min Idle Instances: Agora você pode ajustar o número mínimo de instâncias da sua aplicação que ficarão em execução(de 1 a 100).
  • Max Pending Latency: Aplicações que necessitam de menor latência no acesso, agora podem configurar por quanto tempo uma requisição irá aguardar para ser atendida antes de iniciar uma nova instância da aplicação.
  • Python 2.7: Agora o SDK suporta também esta versão do Python; assim se pode testar aplicações localmente contra a versão 2.7, antes de publicá-las em produção.
  • Map Reduce (Python): Foi liberada uma versão experimental de um framework de Map Reduce, que inclui as fases Map, Shuffle e Reduce
  • Memcache API (Java): A API de memcache agora suporta chamadas assíncronas também para a plataforma Java.
  • Datastore Callback (Java): Pode-se agora especificar ações a serem executadas antes e depois das operações de put e delete no Datastore.
  • Blobstore API: Não será mais necessário habilitar a cobrança de sua aplicação para utilizar a API do Blobstore

Todas as funcionalidades e correções podem ser acompanhadas para ambas as plataformas nas notas da versão, para Python e Java.

Fonte: Rafael Nunes/InfoQ

Closure Stylesheets do Google facilita a manipulação de código CSS extenso

O Google liberou como open source sob a Licença Apache 2.0, o projeto Closure Stylesheets, que define uma extensão do padrão CSS e oferece ferramentas, para facilitar a manipulação de arquivos CSS extensos.

Parte do pacote Closure Tools e criado em Java, o projeto adiciona variáveis, funções, condicionais e mixins ao CSS. Com o Closure Stylesheets o desenvolvedor trabalha com as Google Stylesheets (GSS), que são processadas pela ferramenta para gerar arquivos CSS padrão, usados por aplicações ou sites web.

Variáveis

Variáveis são definidas usando @def:

@def BG_COLOR              rgb(235, 239, 249);
@def DIALOG_BG_COLOR       BG_COLOR;
body {
background-color: BG_COLOR;
}
.dialog {
background-color: DIALOG_BG_COLOR;
}
 
O CSS resultante para o bloco acima é:
 
body {
background-color: #ebeff9;
}
.dialog {
background-color: #ebeff9;
}

Functions

O projeto introduz uma série de funções aritméticas para a manipulação de valores númericos (ex.: medidas em pixels): add(),sub(), mult(), div(), min() e max(). Veja um exemplo com a função add():

@def LEFT_WIDTH    100px;
@def LEFT_PADDING  5px;
@def RIGHT_PADDING 5px;
.content {
position: absolute;
margin-left: add(LEFT_PADDING,
LEFT_WIDTH,
RIGHT_PADDING,
px);

Aqui está o bloco de CSS resultante:

.content {
position: absolute;
margin-left: 110px;
}

Condicionais

O Closure Stylesheets permite o uso de @if, @elseif e @else para a criação de estruturas condicionais baseadas no valor de algumas variáveis.

Mixins

Mixins são estruturas que permitem o reuso de declarações parametrizadas. Veja um exemplo:

@defmixin size(WIDTH, HEIGHT) {
width: WIDTH;
height: HEIGHT;
}
.image {
@mixin size(200px, 300px);
}

Os mixins são especialmente úteis para tratar questões de compatibilidade entre navegadores web:

@defmixin gradient(POS, HSL1, HSL2, HSL3, COLOR, FALLBACK_COLOR) {
background-color: FALLBACK_COLOR; /* fallback color if gradients are not supported */
background-image: -webkit-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);               /* Chrome 10+,Safari 5.1+ */
/* @alternate */ background-image: -moz-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR); /* FF3.6+ */
/* @alternate */ background-image: -ms-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);  /* IE10 */
/* @alternate */ background-image: -o-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);   /* Opera 11.10+ */
}
.header {
@mixin gradient(top, 0%, 50%, 70%, #cc0000, #f07575);
}

O código acima gera o seguinte resultado:

.header {
background-color: #f07575;
background-image: -webkit-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -moz-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -ms-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -o-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
}
 

O Closure Stylesheets também pode ser usado para concatenar vários arquivos CSS em um só e fazer a minificação do código. A ferramenta faz verificações estáticas na sintaxe e é capaz de inverter valores em expressões (RTL flipping), além de renomear classes.

O Closure Tools, o projeto principal que contém o Closure Stylesheets, traz um compilador, uma biblioteca e templates para a manipulação de grandes aplicações JavaScript. As ferramentas são usadas internamente pelo Google, em produtos como GMail, Google Docs e Google Maps. O projeto foi tornado open source em 2009.

Fonte: Abel Avram/traduzido por Leonardo Galvão/InfoQ

Utilizando JSON em projetos iBOLT e uniPaaS

O padrão de notação JSON (“JavaScript Object Notation” http://en.wikipedia.org/wiki/JSON) tem sido bastante utilizado na troca de informações entre aplicações WEB atualmente, isto porque existem alguns ganhos como quantidade de bytes se comparado com XML (http://en.wikipedia.org/wiki/JSON#Comparison_with_other_formats) e o fato de não ser necessário a utilização de parse mais apurado como XML.

Como em nossa tecnologia (iBOLT e uniPaaS) existe a grande facilidade de trabalhar com XML, que tal convertermos JSON para XML? A idéia deste post é se utilizar de um componente JAVA já desenvolvido para o tratamento de JSON e incluir em nossa solução um componente reutilizável para iBOLT e invocar este código JAVA no uniPaaS.

As referências do nosso post são:

1) http://json.org: Descrição de toda notação JSON

2) http://json.org/java/: Código Java que iremos utilizar em nossa solução iBOLT e uniPaaS

3) http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html: Como compilar o código extraído do item 2

4) http://download.oracle.com/javase/6/docs/technotes/tools/windows/jar.html: Como gerar o arquivo .jar para ser incluído na biblioteca do iBOLT e uniPaaS

5) http://devnet.magicsoftware.com/en/library?book=en/uniPaaS/&page=Java_Integration/Type_Signatures.htm: Como saber a assinatura de um objeto JAVA para ser utilizado em uniPaaS.

Preparando nossa biblioteca escrita em JAVA

Faça o download do código fonte que está no item 2 da nossa referência. Neste exemplo colocarei na pasta C:\POST, para seguir a estrutura do JAVA. Como o código foi desenvolvido dentro de um pacote org.json, coloque os arquivos dentro de uma estrutura de pasta org\json, então coloque todos os arquivos no caminho C:\POST\org\json. Veja como ficou nossa estrutura:

Para facilitar o nosso teste no iBOLT e uniPaaS, vamos criar um novo código JAVA, este código fará a conversão do objeto JSON em XML e vice-versa.

Crie um novo arquivo chamado Conversor.java e inclua o seguinte código:

Agora vamos compilar todos estes arquivos *.java, executando simplesmente o comando javac *.java, veja como foi o resultado:

Agora vamos juntar todos os *.class em um único pacote, basta ir para a pasta C:\POST e rodar o comando jar -cvf json.jar org\json\*.class, veja como foi o resultado:

Pronto na pasta C:\POST foi gerado o arquivo json.jar que vamos utilizar no iBOLT e uniPaaS.

Utilizando em iBOLT

Como o iBOLT tem a possibilidade de expandir a capacidade de sua lista de componentes, utilizando o item componente SDK (http://devnet.magicsoftware.com/en/library?book=en/iBOLT/&page=Component_SDK.htm) vamos incluir um novo componente que será capaz de converter um formato JSON para XML e ao contrário.

Pegue o arquivo json.jar gerado no item anterior e coloque na pasta <ibolt_home>\java\lib.

Acesse o menu Tools / Component SDK e clique em New. Coloque as seguintes informações na tela:

Repare que o tipo é Java, e para ficar mais interessante copiei a imagem de http://json.org/img/json160.gif para <ibolt_home>icons\jsonifc.gif.

Clique em Methods e digite org.json.Conversor no campo class name, ao teclar tab aparecerão os métodos. Selecione somente os métodos toXML e toJSON. Veja:

Após clicar em load abrirá uma tela para melhorar a forma de configurar o nosso componente, neste passo é interessante colocar nomes amigáveis em Display Name, neste sentido vamos fazer as seguintes alterações:

No método toJSON, no parâmetro P1 colocar o display name para XML e no parâmetro P_Return colocar o display name para JSON. Em ambos os parâmetros altere o campo Picture para 32000.

No método toXML, no parâmetro P1 colocar o display name para JSON e no parâmetro P_Return colocar o display name para XML. Em ambos os parâmetros altere o campo Picture para 32000.

Clique em OK.

Para gerar o nosso componente e ser possível sua utilização clique em Generate e depois OK e pode fechar a tela atual.

O componente definido nos passos anteriores fica gravado na pasta <ibolt_home>\User resources\Components onde cada pasta significa um componente definido na tela do Componente SDK.

Sempre que precisar utilizar nos projetos o componente colocado no componente SDK você deve acionar o menu Project / Component clicando no botão Add.

Agora já temos um novo componente na lista de componente do iBOLT. Veja:

Agora podemos configurar os métodos, veja:

Observações que devem ser sempre seguidas em ambiente desenvolvimento e produção que utilizarem o componente em questão:

1) O arquivo json.jar deve estar sempre no caminho <ibolt_home>\java\lib

2) O componente SDK deve estar sempre na pasta <ibolt_home>\User resources\Components

Utilizando em uniPaaS

Para o uniPaaS carregar o arquivo json.jar criado anteriormente teremos que acrescentar no magic.ini na seção [MAGIC_JAVA] na configuração CLASSPATH o local onde o uniPaaS poderá encontrar o arquivo json.jar. Neste sentido iremos disponibilizar o arquivo json.jar em uma pasta na própria instalação do uniPaaS no local C:\MSE\uniPaaS1.9h\json por exemplo, veja:

Precisamos alterar no magic.ini na seção [MAGIC_JAVA] na configuração CLASSPATH informando o arquivo json.jar. Veja:

Agora vamos fazer o programa que invoca o código JAVA, imaginando que tivéssemos uma tela desta forma:

A referência da variável JSON é igual a “A” e a referência da variável XML é igual “B”. Basta utilizar a função JCallStatic. Nesta função precisamos passar o nome da classe e método, assinatura e parâmetros. No nosso caso as informações são:

Nome da classe = org.json.Conversor.toXML

Assinatura = (Ljava/lang/String;)Ljava/lang/String; esta informação foi obtida utilizando a nossa referência do item 5.

O parâmetro = JSON que neste caso é a variável A.

Veja como fica nossa expressão:

A expressão acima está sendo utilizada em um update. Veja:

Executando e testando, veja que o objeto JSON é convertido em XML:

CONCLUSÃO

Com a implementação de uma nova funcionalidade em nossa ferramenta, colocamos em prática a possibilidade de interoperabilidade e aumento da capacidade em nossa ferramenta iBOLT e uniPaaS. Com isso, em um exemplo bem prático e simples colocamos a prova de como são simples e poderosas as nossas ferramentas.

Espero que este post tenha ajudado a enxergar no iBOLT e uniPaaS as ferramentas poderosas e versáteis que temos em nossas mãos.

Fonte: Jeronimo Costa/MagicSoftware

Oracle propõe tornar o JavaFX open source

Recentemente, na conferência JavaOne, a Oracle disse que tem a intenção de tornar o JavaFX uma plataforma open source. Agora, a empresa está propondo formalmente que a toolkit JavaFX seja open source sob o projeto OpenJDK e está quer que ela seja incorporada ao Java 9. O arquiteto desktop da Oracle, Richard Bair, ao fazer a proposta, disse que a empresa já vinha conversando a respeito há muito tempo, “mas finalmente estão preparados para atuar nessa área”.

JavaFX foi criado pela Sun como uma tecnologia independente, com sua própria linguagem de script. Mas desde a aquisição da Sun pela Oracle, ela foi reposicionada como uma toolkit Java com uma moderna arquitetura, dando suporte para, por exemplo, aceleração de hardware e estilização utilizando CSS.

O projeto se chamará JFX e a Oracle espera que durante o processo uma comunidade se desenvolva em torno dele; o projeto inclui mais de 6 mil membros de APIs públicas, 11.500 unidades de testes, bibliotecas core, efeitos, suporte a CSS e a aceleração de hardware e controle UI e gráficos. Eles também esperam que a transparência vinda dos códigos open source irá melhorar a aceitação. O código já existe para portar uma camada que suporta Linux, Mac OS X e Windows.

Bair espera que existirá um JSR para JFX a tempo do Java 9, que incluiria JFX como “uma parte adequada do JDK”.A proposta dele formalizada por Iris Clark, que foi quem colocou a proposta para votação. Inicialmente, o projeto – que será liderado por Bair – terá o código JavaFX publicado pela Oracle, começando pelos controles UI. Ao longo dos meses, o código completo será publicado. O OpenJFX não dependerá dos binários por muito tempo. A votação deve ser concluída até o dia 16 de novembro.

Plano a longo prazo da Oracle é ver o JavaFX superar o toolkit UI já existente, como o Swing. Mas não há planos de remover o Swing do Java e é possível usar os dois em um aplicativo. O código fonte para o JavaFX deve ser lançado sob a GPLv2 com a exceção do Classpath.

Com informações de The H

Fonte: IMasters

Update para Java 7 corrige problemas com Apache Lucene

Quando o Java 7 foi lançado, ele veio com uma falha: usado com Apache Lucene e Apache Solr, o Java 7 causava cálculos incorretos e travava a Java Virtual Machine. Lucene e Solr ficavam praticamente paralisados.

Agora, a Oracle confirmou oficialmente que algumas das falhas foram corrigidas no Java 7 Update 1.

O problema foi descoberto alguns dias antes do lançamento do JDK 7, mas não houve tempo para corrigi-lo.

Embora a atualização tenha ficado pronta há alguns dias, as notas de lançamento não continham informações sobre o status dos bugs. Agora as IDs das falhas foram liberadas: 7068051, 7044738 e 7077439; e apesar de o bug 7070134 não estar identificado, ele também foi corrigido.

A Oracle também atualizou as notas de lançamento, confirmando que quatro problemas relacionados a JIT e a loop foram corrigidos.

De acordo com Uwe Schindler, comitter para Apache Lucene e Solr, agora é seguro usar Lucene e Solr com o 7 Update 1. Entretanto, ele aponta que não é recomendável utilizar o XX:AggressiveOpts em qualquer JVM em uso de produção.

Informações publicadas originalmente em The H

Fonte: IMasters