A partir do build 75 o JavaSE8 já contempla a nova api de manipulação de datas, baseada no JodaTime.
É uma JSR de 2007, já não era hora. Felizmente, muitas JSRs que estavam há anos congeladas estão finalmente chegando a ver a luz. O Java 7 trouxe algumas e o Java 8 vem trazendo outras. Era uma vergonha uma linguagem do porte do Java não ter uma API nativa decente pra manipular data e hora.
Apesar de ter acostumado a mexer com Calendar, sempre achei a API do JodaTime muito mais simples e intuitiva. Com certeza essa novidade aí será muito bem vinda
[quote=marcosalex]A partir do build 75 o JavaSE8 já contempla a nova api de manipulação de datas, baseada no JodaTime.
É uma JSR de 2007, já não era hora. Felizmente, muitas JSRs que estavam há anos congeladas estão finalmente chegando a ver a luz. O Java 7 trouxe algumas e o Java 8 vem trazendo outras. Era uma vergonha uma linguagem do porte do Java não ter uma API nativa decente pra manipular data e hora. [/quote]
Bom, vergonha eu não diria tanto. Se o calendar é vergonha, o que é a API do .net ? (que é práticamente um cópia da do java)
Ora, API de data são muito complexas, como o pessoal da nova JSR descobriu. E mesmo a API de Calendar que era um improvment da classe “date” teve algumas falhas - e diga-se que esta API mesmo sendo complexa de usar, faz todo o sentido. O problema é que os programadores não conseguem pensar em coisas tão complexas como esta. As pessoas ainda não sabem que não podem assumir que todos os anos têm 12 meses e todos os dias têm 24 horas. Este forum está cheio de threads de pesoas tentando calcular intervalos e datas na mão. E isto não é problema da API. É problema de falta de conhecimento mesmo. Tlv até das escolas que não explicam este assunto direito ( ou sequer explicam).
Precisávamos de uma API mais mastigada, mais fluente. Mas isso não se provou nada trivial e o fato de só agora termos isso no java 8 ( e realmente espero que venha mesmo e não seja outro hoax como no java 7) deve-se não a que estava congelada, mas a que ha muitos testes envolvidos e muitos casos de uso que têm que ser equacionados e não apenas é uma API de data que por si mesmo é complexo, mas ainda mexe com i18n e com bancos de dados sobre timezones. Quando esta API sair todas as outras plataformas vão chorar e o java mostra que realmente é pensando para aplicações run anywhere. A API teve idas e vindas e quetões de design e refactoring porque o i18n é complexo e ainda mais se vc coloca várias threads no barulho. Então ha que dar parabéns a quem esteve envolvido com isto, e louvar a paciência e capcidade porque não é realmente nada fácil.
A única coisa ruim da API é que o conceito de Duration e Period não corresponde ao conceito físico, mas deve haver alguma razão para isto. É assim no joda time e eu tinha lido que na JSR iriam mudar o conceito para ficar certo, mas segundo o link não foi mudado. Espero que o link esteja enganado. Mas isso é um menor detalhe. E espero que depois do java 8 as pessoas aprendam realmente a mexer com datas e tempos.
No joda time uma Duration é um intervalo de tempo entre dois pontos do timeline. Em fisica isto é um Periodo.
No joda time um Period é um conjunto de campos “humanos” do tipo " 3 horas, 5 dias, 8 anos". Em fisica este conceito não existe, porque só existe a difeerença entre pontos do timeline (fisica é calendar agnostic)
Na minha opinião, os nomes estão trocados. não existem períodos de “3horas , 5dias e 8 anos” , existem durações.
Então por exemplo, um filme que tem duração de 1h e 30 (90min) fariamos
ou
E vai retorna o q? NO caso do joda time, Period. Então ficaria
No caso do filme que é minutos vai dar no mesmo, mas se fosse sei lá , o mandato do Papa , seria mandato.getDuration() e retorna um Period porque são “y anos, m meses, x dias, n horas” Não são milissegundos que importam.
Por outro lado Periodo está associado também a repetições, a coisas periódicas. Então se eu tiver um pendulo e quiser saber o periodo tenho que fazer
Porque eu quero os milissegundos entre duas passagens do pendulo. E mesmo que demore dias, sempre me interessa isso em segundos.
Fica um pouco estranho.
Eu tinha lido que no Java iam trocar chamando Period ao Duration do joda e vice-versa. Mas parece que não vai ser assim… a julgar pelo link que foi passado no principio.
Eu acabei decorando a definição dos dois e do Interval, mas também confundia bastante no início. Hoje costumo lembrar que formato da ISO 8601 para duração/período começa com P, como P10D para 10 dias, e PT36H para 36 horas, e que esse formato usa somente os campos e números.
Com certeza o jodatime ajuda a resolver com facilidades muitos problemas que tínhamos com as outras API, e foi por isso que criei a LTN4Java que não tem um foco em data mais já ajuda bastante no desenvolvimento quando se trata em comparação de data e ainda quero melhora-lá bastante.