terça-feira, 11 de março de 2014

Lançamento do Java 8

O lançamento mundial do Java 8 acontecerá no próximo dia 25 às 14 horas, no horário de Brasília, e as inscrições para o Webcast já estão abertas.

Faça sua inscrição no site do evento.

Além da palestra de lançamento ao vivo, estarão disponíveis mais de 35 sessões técnicas e fórum para perguntas.

Se você quiser enviar perguntas para a equipe de arquitetos da Oracle com antecedência, basta usar a hastag #Java8 no twitter.

Fonte: SouJava

quinta-feira, 6 de março de 2014

JAX-RS 2.0 Jersey Client API - #AdoptaJSR #JSR339

Olá pessoal, esse post faz parte do programa Adote uma JSR com GujavaSC e falaremos hoje sobre a JSR 339 mais especificamente sobre nova funcionalidade Client API. Essa funcionalidade é utilizada para acessar recursos web e fornece uma API de mais alto nível que HttpURLConnection.

O artigo irá mostrar um exemplo de como você pode utilizar a nova Client API do JAX-RS 2.0 do Jersey.

Para esse projeto usaremos o JBOSS AS 7.1 Port 8082 com maven (pom está no github), o objetivo será consumir serviços REST e saber lidar com as respostas retornadas por ele.

Então vamos começar!

Essa primeira linha de código irá criar e retornar uma instância do client.
Client orderClient = ClientBuilder.newClient();
O próximo passo é criar um WebTarget (representa um recurso identificado por uma URI), construir um request e submetê-lo utilizando GET. Nesse exemplo estaremos pedindo por um objeto chamado Order identificado pelo id 1.

WebTarget target = orderClient.target("http://localhost:8082/rest-client-api-example/resources/orders/{id}"); Response response = target .resolveTemplate("id",1) .request(MediaType.APPLICATION_JSON) .get();
Para explicar cada passo do que aconteceu no código anterior iremos quebrá-lo em partes, como você pode ver abaixo:

orderClient.target(URI) - Retornará um Webtarget que representa a URI
target.resolveTemplate("id", 1) - Cria uma nova instância de WebTarget e substitui o template pelo valor passado
target.request(MediaType.APPLICATION_JSON) - Cria uma nova instância de WebTarget e começa a construir uma request com os media types aceitos
target.get() - Invoca o método HTTP GET para o request de forma síncrona e retorna uma Response

Uma outra coisa que você pode notar, é que o objeto da classe WebTarget é imutável quando diz respeito a URI e mutável quanto a sua configuração. Não entraremos em detalhes aqui, porém toda vez que utilizarmos métodos que modifiquem a URI um novo objeto será criado, em contrapartida quando a configuração de um WebTarget é modificada, novas instâncias não serão criadas.

Na última linha do código anterior você poderia usar outro método HTTP como post(), put() ou qualquer outro que você escolher. Depois você só tem que verificar se a Response está OK (Código 200) e ler a entidade. Se você está tentando ler uma List isso funcionará um pouco diferente e eu estarei falando sobre isso à seguir.
 
Então se o serviço estiver rodando e tudo está correto, você receberá a instância de Order do servidor e seus dados serão imprimidos no console.
if(response.getStatus() == Status.OK.getStatusCode()){
    Order order = (Order) response.readEntity(Order.class);
 System.out.println("Id: "+order.getId());
 System.out.println("Name: "+order.getName());
 System.out.println("Price: "+order.getPrice());
}else{
 System.out.println(response.getStatus()+ " "+ response.getStatusInfo());
}

Você provavelmente precisará também requisitar ao servidor listas genéricas e para fazer isso será um pouco diferente. No código abaixo você vai criar um WebTarget com uma requisição, assim como foi passado anteriormente, e ao invés de passar um id você pedirá por toda a lista the /orders.

WebTarget target = orderClient.target("http://localhost:8082/rest-client-api-example/resources/orders");
Response response = target .request(MediaType.APPLICATION_JSON) .get();

O retorno é um pouco diferente quando usamos tipos genéricos, você terá que instanciar uma sub-classe anônima de GenericType passando List que é o que você deseja receber. 
List<Order> orders = response.readEntity(new GenericType<List<Order>>() {});

Fazendo isso você receberá uma lista de Order e assim manipular da maneira que você achar melhor.

O exemplo completo está no github do adoptajsr, fique à vontade para fazer utilizar como quiser. Lá você também encontrará o serviço REST e a implementação do cliente.

Participem do programa Adote uma JSR com GujavaSC se inscrevendo na lista do AdoptaJSR. Após se inscrever mande um email se apresentando e pergunte como participar!

Fonte: GujavaSC

quarta-feira, 4 de dezembro de 2013

Tribunal dos EUA questiona defesa do Google contra Oracle sobre Android

Um tribunal de apelações dos Estados Unidos questionou nesta quarta-feira a alegação do Google de que a Oracle não conta com proteção de direitos autorais sobre certas partes da linguagem de programação Java.

O assunto, em revisão pelo Tribunal de Apelações em Washington, está sendo acompanhado de perto pelos desenvolvedores de softwares no Vale do Silício.

O sistema operacional Android, do Google, é a plataforma para smarphones mais vendida do mundo. A Oracle processou o Google em 2010, alegando que o Google havia incorporado impropriamente partes da linguagem de programação Java da Oracle no Android.

O caso avaliou se a linguagem que conecta os programas - conhecida como interface de programação, ou APIs - podem ser protegidas por direitos autorais.

Em um processo no ano passado em São Francisco, a Oracle alegou que o Android fere seus direitos na estrutura de 37 APIs Java. A Oracle procura cerca de US$ 1 bilhão em compensação pelos direitos.

Os três juízes do painel não disseram quando tomarão uma decisão.

Fonte: Terra

quarta-feira, 16 de outubro de 2013

Artigo afirma que a criptografia do Java compromete segurança no Android

    Um post escrito por George Lukas (não, não é George Lucas) detalhou a criptografia presente nas novas versões do Android e, de acordo com Lukas, ela é "horrivelmente quebrada". O motivo para a falta de segurança seria o uso das cifras SSL RC4 e MD5, ambas consideradas defasadas, nas conexões dos aparelhos com sistema da Google.
    Avançando na análise do código do sistema, é possível concluir que nem sempre o Android utilizou cifras de baixa segurança em suas conexões. Segundo o artigo, versões mais antigas como a 2.2.1 vinham com o padrão AES256-SHA1, e a mudança ocorreu na versão 2.3. O motivo do uso de uma cifra insegura seria o culpado de sempre (quando não é o Flash): o Java. Verificando a documentação de implementação do Java (RI 6), estas cifras são as recomendadas desde 2002 (nos tempos de Sun, ainda). Neste caso, a Google acabou utilizando este padrão para se adequar as sugestões, que em teoria facilitam a compatibilidade entre aparelhos. Além do sistema, o navegador padrão do Android também utiliza esta cifra insegura. Curiosamente, o Chrome "se escapa" da confusão, utilizando AES256-GCM e SHA384. As cifras, ou cypher, são os algoritmos responsáveis pela criptografia de uma mensagem. Eles são os procedimentos para transformar uma mensagem e codificá-la de uma forma que, se alguém interceptar a comunicação, não possa tirar dados ou interferir. O padrão RC4 já é considerado defasado, sendo presente em protocolos inseguros como o WEP (sim, aquele que você não deve usar em seu roteador), enquanto o MD5 foi "quebrado" em 2009.

Fonte: Adrenaline

segunda-feira, 5 de agosto de 2013

Oracle libera GlassFish 4.0

A Oracle lançou o GlassFish Open Source Edition 4.0, considerado o “primeiro servidor de aplicações Java EE 7 do mundo” pela empresa. Ele foi liberado quase quatro anos após o lançamento da versão 3.0.

O novo conjunto de recursos para o GlassFish 4.0 é refletido quase exatamente nas notas de lançamento do Java EE 7. No roadmap do projeto, a Oracle afirmou que “a implementação de referência do Java EE é um subconjunto do GlassFish, portanto o roadmap do servidor está intimamente ligado aos lançamentos do Java EE”.

Algumas das principais novidades no GlassFish 4.0 são: nova API padrão para processamento de JSON em Java, API Java para WebSockets 1.0, Java Batch 1.0, utilitários de concorrência para Java EE 1.0, Java Message Service (JMS) 2.0 e API java para RESTful Web Services (JAX-RS) 2.0.

Outras atualizações incluem: Enterprise Java Beans (EJB) 3.2, contexto e injeção de dependência para o Java EE (CDI) 1.1, Java Persistence API (JPA) 2.1, JavaServer Faces (JSF) 2.2, Java Servlet 3.1, Bean Validation (BV) 1.1, Expression Language (EL) 3.0, Interceptors 1.2, Java Transaction API (JTA) 1.2, JavaServer Pages (JSP) 2.3 e JavaMail 1.5.

O instalador da versão 4.0 pode obtido no centro de downloads do GlassFish. As notas de lançamento apontam que o principal objetivo é permitir que os desenvolvedores comecem a explorar as novidades na plataforma Java EE 7.

Assim, as seguintes funcionalidades do GlassFish Server não foram foco nessa versão: clusters e instâncias padrão, recursos de alta disponibilidade, atualizações e servidor embarcado. Elas foram incluídas, mas podem não funcionar adequadamente com as novas funcionalidades do Java EE 7. O suporte total para clusters, bem como funcionalidades de administração centralizada, são esperados na versão 4.1, que deve ser lançada em 2014.

Além disso, o JCache não faz parte da versão 4.0, estando programado para o Java EE 8. Ben Cotton, membro do grupo de especialistas do JCache (JSR 107), disse ao InfoQ que “embora a JSR 107 tenha perdido o Java EE 7, está muito perto de ser lançada”. Uma versão preliminar foi liberada, e a API está disponível para desenvolvedores que querem testar as capacidades do JCache. A versão final está prevista para o final de 2013.

O GlassFish Open Source 4.0 é livre para uso, mas a Oracle também oferece o Premier Support, que é um contrato pago focado em deploys de produção.

Fonte: IMasters

quinta-feira, 13 de junho de 2013

IBM quer levar Java Virtual Machine para a cloud

A informação foi avançada por Jan Rellermeyer, investigador da IBM Research, que falava numa conferência sobre automação em Austin, no Texas. A ideia é criar a possibilidade de tirar partido da ferramenta em ambientes cloud, criando uma oferta de serviços dinâmicos.

Seria uma forma de garantir uma "experiência de plataforma continua" entre aplicações baseadas no JVM, executadas em dispositivos móveis e na nuvem.

Segundo o responsável, se a investigação chegar a bom porto o Java poderia tornar-se o sistema operativo do futuro, quer para sistemas embutidos, quer para a cloud.

O trabalho da Big Blue explora formas de escalar o JVM numa ótica de Plataform as a Service um processo que, segundo o responsável, ainda poderá ser longo, relata o Network World.

O Java Virtual Machine é um programa de código aberto desenvolvida pela Sun que permite carregar e executar aplicações Java que correm em qualquer software ou hardware com uma versão JVM instalada.

Fonte: Tek

segunda-feira, 3 de junho de 2013

A Oracle revela planos para melhorias de segurança Java

Oracle planeja fazer alterações para reforçar a segurança do Java, incluindo a fixação de seu recurso de verificação de revogação de certificados, impedindo que os applets não assinados sejam executados por padrão e adicionando opções de gerenciamento centralizado com recursos de listas brancas para ambientes corporativos.

Essas mudanças, junto com outros esforços relacionados à segurança, se destinam a "diminuir a exploração e a gravidade das possíveis vulnerabilidades do Java no ambiente de trabalho e ainda fornecer proteções adicionais de segurança para Java operar no ambiente de servidor", disse Nandini Ramani, vice-presidente de engenharia para Java Client e plataformas móveis da Oracle, em um post no blog na quinta-feira.

O post de Ramani, que discute "a dignidade da segurança", aborda indiretamente algumas das críticas e preocupações levantadas por pesquisadores de segurança este ano após uma série de ataques bem sucedidos e generalizada que exploraram zero-day - anteriormente não corrigida - vulnerabilidades do plug-in do Java nos navegadores que compromete os computadores.

Ramani reiterou os planos da Oracle para acelerar o cronograma de patching do Java a partir de outubro, alinhando-a com o cronograma de correção para outros produtos da empresa, e revelou alguns dos esforços da empresa para executar o código de segurança no plung-in do Java.

"A equipe de desenvolvimento Java ampliou o uso de ferramentas de testes automatizados de segurança, facilitando a cobertura regular ao longo de grandes seções de código da plataforma Java", disse ela. A equipe trabalhou com o principal fornecedor da Oracle para serviços de análise de código fonte com a finalidade de ferramentas mais eficazes no ambiente Java e também desenvolveu a chamada "difusão" que são ferramentas de análise para eliminar certos tipos de vulnerabilidades.

A aparente falta de fonte de comentários apropriados no código de segurança e nos testes de garantia de qualidade para Java 7 foi uma das críticas trazidas pelos pesquisadores de segurança, tendo em conta o grande número de vulnerabilidades e críticas que foram encontrados na plataforma.


Ramani também observou os novos níveis de segurança e avisos para applets - aplicações Java baseadas na web - que foram introduzidos no Java 7 Update 10 e Java 7 Update 21, respectivamente.


Estas mudanças foram feitas para desencorajar a execução de applets assinados ou auto-assinado, disse ela. "Em um futuro próximo, por padrão, Java não vai mais permitir a execução de código de auto-assinado ou não assinado."

Tal comportamento padrão faz sentido do ponto de vista de segurança, considerando que a maioria dos exploits Java são entregues como applets Java não assinados. No entanto, tem havido casos de exploits Java assinados digitalmente sendo usados ​​no passado e pesquisadores de segurança esperam que seu número aumente.



Veja a matéria completa em: ComputerWorld.com

Fonte: ComputerWorld.com, traduzido por ALJUG