segunda-feira, 20 de maio de 2013

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

terça-feira, 7 de maio de 2013

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

sexta-feira, 3 de maio de 2013

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)

segunda-feira, 22 de abril de 2013

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

quinta-feira, 28 de fevereiro de 2013

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