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

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

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

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

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

Contribua para a Qualidade do JDK 8

A Oracle libera periódicos instantâneos para o acesso antecipado dos arquivos binários e documentação para o teste do JDK 8 no java.net. Esses matérias instantâneos permitem analisar e contribuir para a plataforma Java SE, uma vez que está sendo desenvolvido. Por favor, baixar as últimas atualizações da visualização do JDK 8,que é a próxima geração do Kit de Desenvolvimento Java. faça um test drive e partilhar o seu feedback. Você pode obter o código fonte através do projeto OpenJDK jdk8. Os Recursos do JDK 8 está na página da lista dos JEPs que atualmente financia e orientados para o desenvolvimento do JDK 8.

Por favor, use o Fórum de comentários do projeto para sugestões ou para encontrar problemas usando JDK 8.

Se você encontrar bugs em um lançamento, por favor envie-los usando os canais de comunicação de erros habituais do Java SE, e não com o rastreador de emissão que acompanha este projeto. Não deixe de incluir informações sobre a versão completa a partir da saída do comando java-version.

A comunidade Java é uma parte integrante de continuar a melhorar a qualidade das versões Java. Estamos aguardando a sua participação!

Faça o da ultima versão do JDK 8  em  https://jdk8.java.net/


Fonte: Blog da Oracle

Inventor do JavaScript defende API Java livre

Quase três dezenas de cientistas de computação opuseram-se à iniciativa da Oracle de impor direitos de propriedade intelectual sobre a API Java. Em uma declaração (amicus curiae) apresentada ao tribunal, o grupo defende que a API proprietária vai atrasar a evolução da indústria de TI.

O grupo inclui nomes proeminentes como o do inventor do MS-DOS, Tim Paterson e o de um dos responsáveis pelo desenvolvimento da ARPANET, Larry Roberts. E apoia a Google no processo na qual a Oracle acusa a gigante das buscas de ter violado os direitos de propriedade intelectual sobre a API Java no desenvolvimento do sistema operacional Android.

A Google nega qualquer irregularidade e argumenta, em parte, que a API Java não é elegível para a proteção de direitos de propriedade intelectual sob a lei dos EUA. No ano passado, um tribunal distrital da Califórnia concordou em grande parte com a Google e decidiu contra a Oracle no caso.

Para o juiz William Alsup,  a API Java não pode ser abrangida  pela legislação em vigor, por ser uma parte funcional da plataforma Java, necessária para o uso da linguagem Java. A Oracle recorreu da decisão, e a iniciativa dos cientistas pretende influenciar o tribunal que decidirá sobre o recurso.

A ação dos cientistas foi proposta pela Electronic Frontier Foundation, em nome de 32 cientistas de computação e programadores de software. Outros signatários são Brendan Eich, inventor do JavaScript e CTO da Mozilla, Michael Tiemann, autor do compilador GNU C++ e executivo da Red Hat, e o responsável pelo desenvolvimento do Samba, Andrew Tridgell.

“A liberdade de reimplantar e ampliar as APIs existentes tem sido um fator chave de concorrência e progresso no campo da informática – hardware e software,” diz a declaração. “Tornou possível o surgimento e sucesso de muitas indústrias robustas hoje consideradas banais, ao assegurar que os concorrentes poderão desafiar empresas já estabelecidas estendendo o estado da arte”.

A declaração argumenta, por exemplo, que a disseminação de PCs de baixo custo foi possível porque a IBM não deteve nenhum direito autoral sobre o seu BIOS, permitindo a concorrentes como Compaq e Phoenix criarem suas próprias implementações de BIOS e criar clones do PC. A natureza aberta da API também foi essencial para o desenvolvimento do sistema operacional UNIX, a linguagem de programação C e os protocolos abertos na Internet, lembra a declaração.

Fonte:CIO

1º Encontro técnico do ALJUG

     Pessoal é com muita felicidade que venho aqui comunicar que no dia 8 de junho estaremos realizando o primeiro encontro técnico do ALJUG. Esse encontro vai ser às 10h da manhã até as 12h no prédio de Analise de Sistemas do Cesmac na sala 704. Como pauta desta reunião estaremos discutindo sobre a evolução do grupo e como evoluir ainda mais, também sobre o evento ALJUG JAVA DAY III, e sugestões de quem comparecer, além disso estamos organizando para que está reunião seja também online, porém em outra data para que todos que quiserem , e estão longe, possa de alguma forma contribuir, a data ainda será definida para o evento online.

Neste encontro teremos um mini curso de Vraptor, com Sergio Holanda programador da empresa IlhaSoft.

Para este evento contamos com o apoio da:

          http://www.casadocodigo.com.br/

     Onde estaremos sorteando alguns livros desta editora para os que comparecerem além também do evento online. Então é indispensável a presença de todos que querem que a comunidade de desenvolvedores Java do Estado de Alagoas cresça ainda mais!

"Somos um em todos e todos em um só nome, ALJUG."

Qualquer novidade estaremos atualizando este post.

Oracle Altera Números para Versões Java

Devido ao grande número de patches de segurança que a Oracle precisou liberar para Java SE, a empresa já teve que mudar a forma como atribui os números de versão para as atualizações lançadas. A Oracle tem enfrentado um problema com sua programação de "Limited Updates", isto é, mudanças de recursos secundários dentro de uma versão Java precisam trabalhar com números de versão previsíveis para a atribuição e relatórios.

O que antes era um sistema previsível tornou-se muito mais difícil de controlar porque cada CPU (Critical Patch Update) para falhas de segurança colidiu até o número da versão. Agora, a Oracle tem construído um novo esquema de numeração que será introduzido pela primeira vez para o JDK 7 e, em seguida, aplicado ao JDK 5.0 e 6, conforme necessário.

Fonte: Uner-Linux

JSR 356, Java API para WebSocket

Um novo artigo, agora sobre OTN / java, pelo Java Champion Johan Vos, intitulado de "JSR 356. A mesma,que faz parte da plataforma Java EE 7, especifica a API que os desenvolvedores Java pode usar quando quiser integrar WebSockets em suas aplicações, tanto no servidor Java quanto no cliente. A API é altamente flexível, e libera para os desenvolvedores independente da execução WebSocket subjacente, evitando assim bloqueio do fornecedor dentro dele e também permite uma maior escolha em bibliotecas e servidores de aplicativos. Os clientes da Web ou clientes nativos pode aproveitar qualquer implementação WebSocket com isso pode mais facilmente se comunicar com um back-end em Java.

Como parte do padrão Java EE 7, servidores de aplicativos compatíveis com todos os Java EE 7 terá uma implementação do protocolo WebSocket que adere a JSR 356. Vos explica:

"Uma vez que se encontram estabelecidos, cliente e servidor WebSocket são simétricos. A diferença entre um cliente e um API API do servidor, portanto, é mínima. JSR 356 define uma API cliente Java, bem como, um subconjunto da API completa exigida em Java EE 7

A API Java para WebSocket é muito poderoso, porque permite que qualquer objeto Java para ser enviado ou recebido como uma mensagem WebSocket.

Basicamente, há três tipos diferentes de mensagens:

* Mensagens baseadas em texto;
* As mensagens binárias;
* As mensagens Pong, que são sobre a conexão WebSocket em si.

Quando se utiliza o modelo de interface orientada, cada sessão pode registar-se, no máximo, um MessageHandler para cada um destes três tipos diferentes de mensagens.

Ao usar o modelo de anotação-dirigido,annotation-driven, para cada tipo de mensagem, um método anotado @onMessage é permitido. Os parâmetros desejados para especificar o conteúdo da mensagem nos métodos anotadas depende do tipo de mensagem.

Confira o artigo ,em inglês,aqui e saiba como integrar WebSockets em suas aplicações.

Fonte: Blog Oracle Texto de Janice J. Heiss  Traduzido por Aljug

MariaDB Java Client 1.1.2 Released

O projeto MariaDB tem o prazer de anunciar a disponibilidade imediata do MariaDB Java Client 1.1.2. Esta é uma versão estável (GA). Veja as notas de versão e changelog para obter informações detalhadas sobre este lançamento e a página sobre o Cliente Java MariaDB no AskMonty na Base de Conhecimento para obter informações gerais.

Fonte: Blog MariaDB

JAVA 7 EE Avança

A próxima versão do Enterprise Java recebeu aprovação da Java Community Process - JCP, de acordo com um post no blog da Oracle na terça-feira.

No seguimento, o Java EE (Enterprise Edition) 7 implementação de referência, é colocado como o servidor de aplicação GlassFish. A 7 Plataforma Java EE e Web Perfil JSR (Java Specification Request) passou pela votação para aprovação final do Comitê Executivo da JCP. "Isso conclui o processo de aprovação do JCP para todas as JSRs sob o perfil Java EE 7," DeMichiel escreveu.

Destaque no Java EE 7 são as capacidades de lote, WebSocket, JSON (JavaScript Object Notation) e utilitários de simultaneidade para aplicações assíncronas. Quatorze JSRs estão ligados a Java EE 7, incluindo os Utilitários para Java, Java Persistence 2.1, Java Servlet 3.1, JavaServer Faces 2.0 e Java Message Service 2.0.

Também faz parte do Java EE 7 nove RMs (versões de manutenção), incluindo Web Services para Java EE 1.4, JavaServer Pages 2.3 e Anotações comuns para a plataforma Java 1.2.

Outro recurso que havia sido programado para Java EE 7, a norma da API de cache a JCache, foi excluído da lista de recursos Java EE 7. Espera-se para ser um candidato para Java EE 8, prevista para 2015.

A Oracle tem tido problemas ultimamente com o cumprimento das suas características ambiciosas e metas para edições Enterprise e padrão do Java. A edição padrão do Java 8, que tinha sido previsto para este ano, já está prevista para ficar pronta no próximo ano.

Fonte: InfoWorld (Com adaptações)

Lançamento da versão 8 do Java será adiado até 2014

A Oracle irá adiar o lançamento do Java 8 até 2014, citando um novo foco em mais segurança, disse Mark Reinhold, arquiteto-chefe da plataforma em um post em seu blog nesta quinta-feira (18).

O Java Development Kit 8, baseado na Java Platform Standard Edition 8, estava previsto para setembro deste ano, mas Reinhold diz que ele será adiado para permitir mais trabalho na correção de problemas de segurança que vem assolando a plataforma recentemente. “A Oracle está comprometida a continuar corrigindo problemas de segurança em ritmo acelerado, a aprimorar o modelo de segurança do Java e a introduzir novos recursos de segurança. Este trabalho irá exigir mais horas de trabalho do que temos disponíveis mesmo eliminando recursos do Java 8 ou reduzindo o escopo desta versão”, disse Reinhold.

“Como consequência do renovado foco em segurança a execução do cronograma do Java 8, com um lançamento geral no início de setembro, não é mais possível”. A nova data prevista para o lançamento do software é o primeiro trimestre do próximo ano, com uma amostra para os desenvolvedores programada para setembro, disse ele.

A Oracle também tem visto atrasos no Project Lambda, uma das principais atrações do Java 8 que aprimora os recursos de programação para sistemas com múltiplos núcleos, mas espera concluí-lo no início de maio, três meses depois do planejado. A empresa poderia eliminar o Lambda e cumprir o cronograma originalmente previsto para o lançamento do Java 8, mas isso tornaria esta versão menos atraente, disse Reinhold. “Uma versão sem o Lambda lançada neste ano teria menos probabilidade de ser amplamente adotada, então pra que nos incomodarmos com isso?”.

Al Hilwa, um analista do IDC, concorda com o raciocínio de Reinhold. “Claramente houve uma realocação intencional de recursos para tornar o Java mais seguro, o que é absolutamente a prioridade certa”, disse ele. “O atual cronograma de lançamento do Java é baseado em recursos, e um recurso chave da JDK8 é o Lambda. Acredito que a explicação de Mark e o plano sugerido são sólidos e me parecem ser a melhor opção. É claro que é preocupante, já que a data de lançamento mudou mais de uma vez, mas dadas as circunstâncias atuais, é completamente compreensível.”

Enquanto isso Java SE 9 agora tem um lançamento previsto para 2016, enquanto anteriormente estava programado para 2015. A versão 9 incluirá um sistema de módulos conhecido como Project Jigsaw, que inicialmente seria incluso no Java SE 8.

Fonte: IdgNow

Java Time: API já está disponível no Java 8

A implementação de referência da JSR 310 (API Date and Time), denominada ThreeTen, foi inserida no JDK 8 Early Access b75 sob o pacote java.time, diferentemente das versões anteriores, em que ficava no pacote javax.time. O rascunho do Javadoc da API também foi disponibilizado.

Todas as classes da API Java Time são imutáveis e thread-safe. Além disso, são baseadas na norma ISO 8601, o calendário internacional segundo as regras Gregorianas. Outros sistemas de calendário também são suportados pelos pacotes java.time.calendar e java.time.temporal. Além das classes para data e hora, a API também fornece classes para relógios, períodos e intervalos de tempo, e enumerações para meses e dias da semana.

Há muitas classes na API Java Time, mas a maioria das aplicações podem iniciar com os seguintes tipos de data/hora:

Instant
    É um timestamp numérico armazenado com precisão de nanossegundos. Útil para capturar um instante no tempo, similar ao método System.currentTimeMillis(). A classe Instant é a mais próxima em equivalência à classe java.util.Date. Quando impreso, um instante assemelha-se a '2000-12-01T12:30:00.000Z'.
LocalDate
    Representa uma data sem hora ou fuso horário. Útil, por exemplo, para armazenar datas como a de um aniversário. Quando impressa, uma data assemelha-se a '2000-12-01'.
LocalTime
    Representa um horário sem data ou fuso horário. Um exemplo de utilização é o armazenamento de horários de lojas. Quando impresso, um horário assemelha-se a '12:30:00.000'.
LocalDateTime
    Representa uma data e hora sem o fuso horário. A impressão de uma data/hora assemelha-se a '2000-12-01T12:30:00.000'.
ZonedDateTime
    Representa uma data e hora com o fuso horário. Útil para realizar cálculos que levam em consideração o fuso horário, como 'America/New_York'. A classe ZonedDateTime é a mais próxima em equivalência à classe java.util.GregorianCalendar. A impressão de uma data/hora assemelha-se a '2000-12-01T12:30:00.000-05:00[America/New_York]'.

Sempre que possível, é recomendável utilizar classes mais simples e sem fuso horário para modelar os objetos de domínio, como LocalDate, LocalTime e LocalDateTime. O uso generalizado de fusos horários pode adicionar uma complexidade considerável a uma aplicação. Muitas aplicações podem utilizar classes mais simples e adicionar o fuso horário somente na camada de apresentação.

Outras classes notáveis na API Java Time são:

Clock
    Um clock fornece acesso ao instante corrente, data e hora, usando um fuso horário. Pode ser utilizado no lugar dos métodos System.currentTimeMillis() e TimeZone.getDefault(). Embora todas as principais classes de data e hora tenham um metódo de fábrica denominado now(), que utiliza o relógio do sistema, o principal objetivo desta abstração é permitir que relógios alternativos sejam injetados, o que simplifica bastante os testes.
Duration
    Representa uma duração entre dois instantes na linha do tempo, armazenada com a precisão de nanossegundos. Esta classe modela uma duração de tempo sem estar ligada a qualquer instante. O modelo é direcionado, significando que a duração pode ser negativa. Na impressão, uma duração assemelha-se a 'PT3600S'.
Period
    Representa um período de tempo expresso em unidades que fazem sentido aos humanos, como '1 ano, 2 meses e 3 dias'. O modelo é direcionado, significando que partes individuais do período podem ser negativas. A impressão de um período é semelhante a 'P1Y2M3D'.
ZoneId
    Representa um identificador de fuso horário (área), como America/New_York.
ZoneOffset
    Representa a diferença de horário a partir do meridiano de Greenwich/UTC. Como, por exemplo, +02:00.

O pacote java.time.zone fornece suporte a fusos horários, suas regras e as lacunas ou sobreposições na linha do tempo local, causadas tipicamente pelos períodos de Horário de Verão. Há também o pacote java.time.format para impressão e parsing de objetos do tipo data/hora (embora na maioria dos casos os métodos toString() e parse() dessas classes sejam suficientes). O pacote java.time.temporal fornece acesso à data e hora através do uso de campos e unidades, além de classes adicionais para as subpartes mais importantes de uma data, e suporte base para calendários que não atendam aos padrões ISO. Fornece também funcionalidades adicionais para os casos mais avançados.

Os usuários que quiserem testar a nova API Java Time, podem baixar o JDK 8 b75 e utilizar o Javadoc como guia. Se quiserem também uma IDE com suporte ao JDK 8, podem usar a última versão das IDEs IntelliJ IDEA ou Netbeans. Aqueles que estão em busca por tutoriais de terceiros, devem se certificar de que estão olhando os artigos mais recentes, pois a API sofreu muitas mudanças nos últimos anos. Considere também que mudanças nas classes e métodos da API Java Time poderão continuar ocorrendo até que o JDK 8 seja definitivamente lançado. Desenvolvedores interessados em conhecer todas as novas funcionalidades do JDK 8 e também saber quando serão de fato incluídas, podem verificar a lista de funcionalidades e mudanças do JDK.

O InfoQ cobriu o anúncio da JSR 310 no começo de 2007, quando a distribuição da JSR foi originalmente planejada para o JDK 7. O InfoQ também entrevistou Stephen Colebourne, líder da JSR 310, durante a primeira revisão dos rascunhos da JSR em 2010. A última cobertura da JSR 310 pelo InfoQ foi feita em setembro de 2012, quando a JSR foi oficialmente adicionada à lista de funcionalidades do Java 8.

Nota do ALJUG: Lembrando que para algumas funcionalidades como a comparação de datas foi criada uma biblioteca que facilita, além de outras funcionalidades que estão neste jar , que se chama LTN4Java, além disso a mesma continua em desenvolvimento, para qualquer detalhe sobre esta biblioteca acesse a página do projeto.

Fonte: InfoQ

Oracle sem chão com mais duas falhas de segurança no Java 7

Um grupo de investigadores polacos alertou para a existência de duas falhas nunca antes detetadas no Java 7 para navegadores de Internet. A Oracle já está a par da situação e está a investigar as provas reunidas pelos programadores de leste para trabalhar numa solução.

A empresa Security Explorations enviou à tecnológica norte-americana provas da possibilidade de execução de código malicioso nos computadores vulneráveis. Como relata o ZDNet, num dos bugs identificados a Oracle considera que é um "comportamento permitido", o que mostra o lado permissivo e pouco rígido com que a criadora do plug-in aborda a questão da segurança.

O Java tem estado debaixo de fogo nos últimos meses devido às constantes vulnerabilidades que são encontradas, e a par do Adobe Reader, são consideradas como as principais causas que levaram à invasão de dispositivos de empresas como o Facebook, a Apple e o Twitter.

O investigador Adam Gowdiak, da empresa de segurança polaca, em declarações ao Computer World mostrou-se surpreendido pelos ataques que as gigantes tecnológicas sofreram nos últimos tempos devido às falhas no Java.

Em 2013 a Oracle já endereçou duas correções de alta prioridade para reparar os bugs até então descobertos. Alguns investigadores consideram as atualizações inconsequentes e dizem mesmo que seriam precisos dois anos para que a empresa responsável pelo Java 7 conseguisse eliminar todos as vulnerabilidades.

Alguns especialistas de cibersegurança citados pela imprensa internacional estão a aconselhar de novo todos os internautas a desativarem o plug-in dos browsers e a utilizarem-no apenas quando for mesmo necessário.

Fonte: Tek

Oracle libera Update 13 do Java e corrige 50 vulnerabilidades

A Oracle anunciou ontem (01/02/13) que liberou o Java7 Update 13, que corrige 50 vulnerabilidades. Destas, 44 afetam especificamente o plugin do software em navegadores - ou seja, podem ser exploradas em desktops por meio de aplicações web e applets Java.

Segundo o site The Next Web, a atualização vem completamente fora de escala - ela foi originalmente programada para 19 de fevereiro, mas o motivo para a pressa é que a empresa foi notificada sobre "uma das vulnerabilidades estar sendo ativamente explorada na rede e afeta o Java Runtime Environment dos browsers".

Curiosamente, a Oracle pulou o update 12 e ainda não está claro o porquê.

Para quem ainda está utilizando o software, a atualização pode ser baixada diretamente no site da Oracle.

Fotne: Idgnow

Apple se recusa a usar o Java 7

A Oracle, empresa responsável pelo plugin Java, chamou bastante atenção nos últimos tempos — e isso não foi uma coisa boa. Tudo começou com a descoberta de brechas na segurança do seu produto, o que possibilita o ataque de hackers a todas as pessoas que tinham o software no seu computador.

Assim que os problemas começaram a chamar atenção, a Oracle lançou uma atualização para acabar com as falhas de segurança. Contudo, vários especialistas alegam que o Java ainda não é seguro e, ao que tudo indica, a Apple concorda com todos os alertas que foram dados até o momento.

O fato que comprova a concordância da Apple é a decisão que ela tomou de não usar o Java 7, a última versão lançada do plugin para navegadores. A empresa está usando um software chamado Xprotect, com o objetivo de bloquear todas as versões do software da Oracle e bani-las dos seus aparelhos.

Além disso, órgãos de segurança continuam alegando que o plugin não é seguro — ou seja, se você realmente se importa com a segurança do seu computador, é aconselhável desativar o funcionamento do produto da Oracle o quanto antes.

Fonte: TecMundo

Para especialista em segurança, Java deve ser reescrito do zero

Se a última vulnerabilidade do Java significa alguma coisa, é que está na hora de a Oracle reescrever a linguagem de programação.

Ao menos é o que acha Bogdan Botezatu, analista sênior de ameaças online da Bitdefender. A empresa de antivírus com sede na Romênia estima que ao menos 100 milhões de computadores estejam vulneráveis a ataques por conta da última vulnerabilidade 0-day do Java.

"A Oracle precisa pegar alguns componentes centrais do Java e escrevê-los do zero", disse o especialista, em uma entrevista.

O problema com produtos mais maduros, como o Java e os da Adobe, é que eles passaram por muitas mãos ao longo dos anos. "Esses produtos se tornaram tão grandes e foram desenvolvidos por tantos programadores que as fabricantes muito provavelmente perderam o controle sobre o que está no produto", disse Botezatu.

Lutando contra falhas

Os resultados dos recentes esforços da Oracle em corrigir as vulnerabildiades em Java reafirmam o que o especialista da Bitdefender disse.

Por exemplo, a Oracle corrigiu três vulnerabilidades em segurança em agosto de 2012, juntamente com o lançamento do Java 7, versão 7 rev. 7. Algumas horas depois de liberar o patch, o fundador e CEO da Security Explorations, Adam Gowdiak, encontrou uma vulnerabilidade causada pela atualização.

Alguns especialistas em segurança dizem que o Java sobreviveu ao seu papel, mas suas funções são manipuladas por outras tecnologias.

A última vulnerabilidade 0-day encontrada na linguagem de programação pode também ser atribuída a uma correção feita pela atualização de segurança liberada em outubro do ano passado. Essa atualização estava incompleta e abriu uma brecha para a vulnerabilidade descoberta na semana passada, de acordo com Gowdiak.

"Agora é uma boa hora para reescrever alguns dos principais componentes do início e garantir que eles estejam livres de bugs, em vez de continuamente liberar correções para a aplicação, de uma versão para outra", disse Botezatu.

O analista reconhece, no entanto, que isso é improvável de acontecer. "A Oracle não está aberta a fazer grandes mudanças, porque eles poderiam quebrar aplicações já existentes no mercado", acrescentou.

O problema que a empresa enfrenta com o desenvolvimento do Java é o mesmo que enfrentam todas as fabricantes de softwares: como melhorar um programa sem que destrua a compatibilidade com as versões anteriores?

"Olhe para o Windows Vista e veja como ele falhou em sua adoção, porque alguns aplicativos dos consumidores não funcionavam do XP para Vista", explicou Botezatu.

No entanto, alguns sinais indicam que a Oracle está tentando resolver algumas das questões levantadas por Botezatu. Na sexta-feira (12/1), a empresa anunciou que, começando pelo lançamento do Java 8 em setembro, novos lançamentos serão feitos por um cronograma de dois anos.

Fonte: ComputerWorld

Java EE 7: Evoluções recentes na especificação

A especificação do Java EE 7 (JSR 342), chegou, no final de 2012, à primeira versão para revisão há uma série de questões em aberto, incluindo quais APIs devem ser adicionadas nos profiles Full e Web, bem como a melhor forma de alinhar o CDI com o Java EE.

Embora o escopo do Java EE 7 tenha diminuído - em particular, os planos para melhorar o suporte de multi-inquilinos (multi-tenancy) para provedores de PaaS foram adiados para o Java EE 8 - a especificação ainda inclui atualizações importantes. Entre elas, estão planejadas novas APIs para processamento em lote; a JCache, uma API de cache temporário de longa duração; uma nova API para processamento de JSON e o suporte a Web Socket e HTML5.

Além disso, três APIs antigas estão sendo restruturadas e melhoradas:

• A JAX-RS 2.0, a API Java para serviços web RESTful, ganha uma nova funcionalidade para clientes REST, HTTP assíncrono no lado servidor, filtros e interceptores;
• A Expression Language 3.0 recebe suporte para a execução de EL fora do container web, assim como novos operadores, expressões lambda e outras funcionalidades;
• A JMS 2.0, enfatiza a simplicidade, implementando a interface do Java 7 java.lang.AutoCloseable para os objetos JMS, facilitando com isso a definição de recursos no Java EE. Além disso, o JMSXDeliveryCount será obrigatório, facilitando a manipulação de poison messages. (Uma poison message é uma mensagem numa fila, que excedeu o número máximo de tentativas de entregas para a aplicação de destino). Os novos recursos incluem a capacidade de um cliente JMS agendar entregas futuras de mensagens; e de enviar mensagens, retornando imediatamente sem bloquear, até que uma mensagem de confirmação tenha sido recebido pelo servidor.

A lista completa das atualizações planejadas é a seguinte:

• Batch Applications for the Java Platform (JSR 352)
• Bean Validation 1.1 (JSR 349)
• Context & Dependency Injection 1.1 (JSR 346)
• Enterprise JavaBeans 3.2 (JSR 345)
• Expression Language 3.0 (JSR 341)
• Java API for JSON Processing (JSR 353)
• Java API for RESTful Web Services 2.0 (JSR 339)
• Java API for WebSocket (JSR 356)
• Java Message Service 2.0 (JSR 343)
• Java Persistence API 2.1 (JSR 338)
• JavaServer Faces 2.2 (JSR 344)
• JCACHE Java Temporary Caching API (JSR 107)
• Java Servlet 3.1 (JSR 340)

O Java EE 6 foi lançado no dia 10 de dezembro de 2009; isso significa que o tempo entre o lançamento do EE 6 e o EE 7 será de mais de três anos - o período mais longo na história da especificação. Acompanhe o andamento do novo Java EE no site Aquarium da Oracle.

Fonte: InfoQ

Oracle confirma correção para o Java

A Oracle reagiu ao anúncio feito pelo departamento americano de Segurança Interior e disse que corrigirá a falha do software Java.

Até o momento, a empresa não confirmou a data de liberação da correção do bug. O departamento, responsável por situações informáticas de urgência, divulgou recentemente uma nota sobre o erro e desaconselhou o uso da aplicação. Além disso, empresas de segurança confirmam a brecha na segurança.
Esta falha permite, por exemplo, que hackers instalem aplicativos maliciosos no computador do usuário e acessem dados bancários e senhas.

De acordo com a Kaspersky, empresa desenvolvedora de soluções de segurança, o Java foi responsável por metade das falhas de segurança identificadas em 2012.

Fonte: Info

5 Motivos para animar-se com Java em 2013

  Com 2012 já era, é hora de olhar para frente nos próximos 12 meses para o desenvolvimento mundial. Ao longo dos últimos dias, nós pedimos alguns desenvolvedores respeitados por suas previsões - agora é hora para o nosso próprio.

Aqui está cinco razões rápidos por que você deve ser animado sobre o que 2013 reserva

1. JAVA 8 

  Para começar, é obvio para a maioria dos desenvolvedores Java, é o lançamento do Java 8 em 2013. Assumindo que não há mais atrasos, podemos esperar Java 8 para chegar em setembro, trazendo com ela as funções, tão aguardadas, lambda.

  É bastante provável que no rescaldo do Java 8 de boas-vindas, vamos ver vários post de blogs comentando ou criticando as complexidade dos novos recursos ou dizendo que a liberação não é grande o suficiente para justificar o interesse.

  De qualquer maneira, alguns recursos necessários, finalmente  irão fazer uma aparição e do resto de nós só vai junta para baixo. A melhorada na API Date and Time dentro de Java 8 também merece uma menção aqui.(lembro aqui do LTN4JAVA)

2. Linguagens da JVM ir de força em força 

   2012 foi realmente o ano das linguagens JVM que tomou o centro do palco. Na frente da embalagem foi a multi-paradigma Scala, auemnto o número de  clientes empresariais graças ao investimento em impressionantes typesafe. Ampliando as possibilidades de Akka e 2,0 Play!, Parece que os fundamentos estão no lugar para alargar ainda mais em 2013. O verdadeiro desafio está vendendo Scala para aqueles que não precisam fazer algo pesado.

  O dinamismo do Groovy  não estava muito atrás no ano passado, acrescentando compilação estática na mistura com Groovy 2.0. Uma terceira versão é esperado, não muito tempo depois do Java 8, para permitir que desenvolvedores Groovy obtenha o máximo dos novos recursos. O elenco de apoio, incluindo Gradle e Grails, pode ser um grande atrativo para quem procura uma alternativa Java.

  Nós não mencionamos nomes como Clojure, JRuby e Kotlin, o último irá sofrer muito trabalho, uma vez que se aproxima uma versão final. Em última análise, o sucesso se resume ao fomento de uma comunidade ativa, que muitas línguas JVM têm cottoned e os projetos spinoff dentro dessa comunidade.

Se 2012 foi o ano do crescimento, 2013 é a consolidação dentro dos círculos empresariais, que é alimentado pelos desenvolvedores usando a linguagem. 

3. A importância crescente de JavaScript em Java 

  Detalhes eram finos no chão para duas novas iniciativas no OpenJDK para 2012, mas até o final do ano, tínhamos aprendido um pouco mais sobre os objetivos de cada projeto e sua importância para a inovação da linguagem Java. O conjunto de novo motor JavaScript incluído no Java 8 vai incorporar JavaScript em aplicações Java. O projeto Nashorn consolida a noção de ressurgimento JavaScript e cada vez mais a importância para os desenvolvedores Java.Inicialmente em sigilo, o Nashorn foi liberado em novembro e apareceu no repositório OpenJDK quatro dias antes do Natal. Outro grande ponto positivo para Nashorn é a inclusão crucial de Node.js descontroladamente populares dentro do negócio, dando início a um futuro poliglota. Com detalhes muito mais definidos para vir, nós estaremos monitorando com olhos de águia. 

4. Ficando mais estrondo para seu fanfarrão - aproveitando a GPU

   Outro projeto dentro do OpenJDK que tem um grande potencial é o Sumatra, com o objetivo de aproveitar melhor desempenho Java, utilizando a GPU. As investigações iniciais estão centradas na JVM Hotspot para estabelecer as bases, antes de 'alavancar' biblioteca Java 8 e linguagens de recursos como lambdas para testar as técnicas de ponta com Java.O projeto, liderado pelo  GPU especialista AMD, espera encontrar alguns obstáculos no caminho com a API Java e suas construções, por isso não vamos ver ideias implementadas no Java 8, mas Sumatra pode gerar grandes avanços e novas técnicas para baixo a linha para os desenvolvedores. 

5. Java deriva ainda mais para a nuvem 

  Com dezenas de IaaS e PaaS opções que inundam o mercado, tanto de indies como Jelastic e gigantes da indústria, como Oracle e AWS, os desenvolvedores estão agora muito por onde escolher. Java, ao que parece, conseguiu fazer o salto para o admirável mundo novo da "nuvem".O maior problema atual, como destacado por Martijn Verburg no blog Java Calendário do Advento, é a falta de padronização e otimização. Com própria nuvem Java, este foi adiado a apresentação para Java EE 8, é agora para fornecer padrões como o CAMP ou, na sua falta, a comunidade está indo para cima com estruturas universais como jclouds. Enquanto isso, outros se recusam a esperar pacientemente para Oracle fornecer recursos como multitenancy e coleta de lixo eficiente, como Waratek (que é esperado para setembro). 

  Com plataformas de nuvem rapidamente se tornando uma norma, estamos propensos a ver o lançamento de ainda mais soluções de terceiros para suportar Java na nuvem: no momento o Java EE 8 não tem data para lançamento (possivelmente 2014).

Texto de Chris Mayer

Tradução e Adaptação: Aljug 

Fonte: JaxEnter