Artigo Java Magazine 69 - Novos tempos: javax.time

Novos tempos: javax.time

Conheça a nova especificação de Data e Hora

Você irá conhecer a nova API de data e hora da plataforma Java. Construída como uma opção ao uso de java.util.Date e java.util.Calendar, vem com duas premissas: facilidade de uso e correção de bugs e falhas arquiteturais de suas antecessoras

De que se trata o artigo:

O artigo aborda o resultado da JSR-310, a JSR que está definindo a nova API de data e hora que será incorporada na plataforma Java. A arquitetura e as principais classes e interfaces da API são discutidas e exemplificadas. Além disso, são abordadas as lacunas presentes nas classes atuais (Date e Calendar) e como a javax.time endereça tais problemas.

Para que serve:

Apresentar a nova API de datas e horas que será incorporada na plataforma Java, provendo discussões sobre a sua arquitetura e exemplos de uso da API, além de comparações com as classes atuais.

Em que situação o tema é útil:

O tema é importante para qualquer um que deseje estar atualizado sobre as novas tendências da plataforma Java. A manipulação de datas e horas é peça-chave em qualquer implementação e a criação de uma nova API tende a facilitar muito a vida do desenvolvedor.

Novos tempos: javax.time:

O artigo aborda a nova API para representação de datas e horas da plataforma Java e como ela facilita a vida do desenvolvedor Java, corrigindo bugs e endereçando problemas das classes atuais Date e Calendar. A nova API possui representações distintas para datas que serão utilizadas para cálculos computacionais e datas que serão utilizadas por seres humanos. Além disso, temos representações padrão para tipos de dados que atualmente precisamos criar como durações, períodos e intervalos.

 Neste artigo conheceremos a nova API de data e hora que está sendo elaborada para a plataforma Java SE 7. O foco da nova API é resolver vários problemas que afetam os desenvolvedores Java há anos, presentes nas classes java.util.Date e java.util.Calendar.

Por que uma nova API?

A arquitetura elaborada para as classes Date e Calendar, ambas do pacote java.util é bastante questionável. Veremos algumas dessas decisões arquiteturais dúbias, além de “bugs” da API atual, no decorrer do artigo.

Outro grande problema é a falta de tipos para representar unidades comuns no dia-a-dia de qualquer desenvolvedor como, por exemplo, períodos, instantes, durações, entre outros. Sem classes que representem essas unidades do “mundo real”, é necessária a criação de soluções paliativas por conta e risco dos desenvolvedores. Isso resulta em mais codificação e código legado para manutenção.

Esses pontos claramente abrem espaço a uma nova abordagem para o tratamento de datas e horas dentro da plataforma Java.

Alguns dos problemas apresentados por Date e Calendar

Um dos principais problemas das classes atuais é a inconsistência. A classe java.util.Date não representa uma data, mas sim um instante na linha do tempo. Desta forma, não temos como representar somente uma data ou somente o tempo. Outro exemplo de inconsistência é o fato da classe Date utilizar anos com base em 1900, enquanto a Calendar requerer os anos completos, incluindo o século. O código apresentado a seguir, apesar do uso de um construtor descontinuado (deprecated), ilustra a criação de uma data cujo ano será 3909, ao contrário do que parece ao ler o código.

Date date = new Date(2009, 2, 1);

O início dos meses em 0 (Zero) na classe Calendar também é algo que tem atrapalhado a vida dos desenvolvedores Java de forma considerável. Por exemplo, para criar uma instância de Calendar que represente a data 01/01/2009, temos que escrever o seguinte código:

Calendar calendar = new GregorianCalendar(2009, 0, 1);

Além disso, temos uma série de outros problemas arquiteturais ou de implementação:

·         Os objetos são mutáveis, inseguros em ambiente multi-thread, requerendo sincronização;

·         Não há como formatar uma instância de Calendar usando as classes do pacote java.text;

·         Não existe opção para representar períodos ou durações de forma padronizada;

·         As APIs atuais exigem muito código para tarefas rotineiras de manipulação de datas e horas. Sem mencionar ainda que muitas dessas “tarefas rotineiras” constituem casos de uso comuns e poderiam ser implementados pelas próprias APIs.

Esses são apenas alguns dos problemas que a JSR 310[1] irá resolver. Os já velhos conhecidos problemas devido às alterações no horário de verão também estão sendo endereçados. Além de tudo isso, você verá que a API é muito mais intuitiva e irá lhe poupar muitas e muitas linhas de codificação.

Princípios de Design da JSR 310

A JSR 310 tem sido elaborada com alguns princípios para facilitar seu uso e entendimento e tornar seu código mais robusto e de fácil leitura.

Baseada em padrões

A nova API está sendo construída totalmente alinhada com o ISO-8601, um padrão internacional para representação de datas e horas.

"