Haruskah saya menggunakan kelas tanggal dan waktu Java atau pergi dengan perpustakaan pihak ke-3 seperti Joda Time?


147

Saya membuat sistem berbasis web yang akan digunakan di negara-negara dari seluruh dunia. Salah satu jenis data yang harus disimpan adalah tanggal dan waktu.

Apa pro dan kontra dari penggunaan kelas tanggal dan waktu Java dibandingkan dengan perpustakaan pihak ketiga seperti waktu Joda ? Saya kira perpustakaan pihak ketiga ini ada karena alasan yang bagus, tapi saya sendiri belum pernah membandingkannya.


5
Untuk mengklarifikasi beberapa komentar ... Sementara Joda-Time berlanjut, penggantinya JSR 310: Date and Time API memang dijadwalkan untuk menjadi bagian dari Java 8 di bawah paket java.time . Oracle memiliki konsep tutorial . JDBC 4.2 akan menangani tipe data baru.
Basil Bourque

Jawaban:


197

EDIT: Sekarang Java 8 telah dirilis, jika Anda dapat menggunakannya, lakukanlah! java.timebahkan lebih bersih daripada Joda Time, dalam pandangan saya. Namun, jika Anda macet sebelum Java-8, baca terus ...

Max meminta pro dan kontra menggunakan Joda ...

Pro:

  • Ini bekerja dengan sangat baik. Saya sangat curiga ada lebih sedikit bug di Joda daripada perpustakaan Java standar. Beberapa bug di perpustakaan Java sangat sulit (jika bukan tidak mungkin) untuk diperbaiki karena desain.
  • Ini dirancang untuk mendorong Anda untuk berpikir tentang penanganan tanggal / waktu dengan cara yang benar - memisahkan konsep "waktu lokal" (mis. "Bangunkan saya jam 7 pagi di mana pun saya berada") dan seketika dalam waktu ("Saya menelepon James jam 3 sore PST; mungkin bukan jam 3 sore di mana dia, tapi ini instan yang sama ")
  • Saya percaya ini memudahkan untuk memperbarui basis data zona waktu, yang memang sering berubah
  • Ini memiliki cerita yang bagus kekekalan, yang membuat hidup banyak lebih mudah IME.
  • Memimpin dari kekekalan, semua pemformat adalah thread-safe, yang sangat bagus karena Anda hampir selalu ingin menggunakan kembali formatter tunggal melalui aplikasi
  • Anda akan memiliki permulaan belajar java.timedi Java 8, karena mereka setidaknya agak mirip

Cons:

  • Ini adalah API lain untuk dipelajari (meskipun dokumennya cukup bagus)
  • Ini perpustakaan lain untuk dibangun melawan dan digunakan
  • Saat Anda menggunakan Java 8, masih ada beberapa pekerjaan untuk memigrasi keahlian Anda
  • Saya telah gagal menggunakan yang DateTimeZoneBuilderefektif di masa lalu. Ini adalah kasus penggunaan yang sangat langka.

Untuk menanggapi gagasan oxbow_lakes untuk secara efektif membangun API kecil Anda sendiri, berikut adalah pandangan saya mengapa ini adalah ide yang buruk:

  • Itu bekerja. Mengapa bekerja ketika itu sudah dilakukan untuk Anda?
  • Pendatang baru di tim Anda lebih mungkin mengenal Joda daripada dengan API buatan sendiri
  • Anda kemungkinan akan melakukan kesalahan untuk apa pun di luar penggunaan paling sederhana ... dan bahkan jika pada awalnya Anda berpikir Anda hanya membutuhkan fungsionalitas sederhana, hal-hal ini memiliki kebiasaan tumbuh lebih rumit, sedikit demi sedikit. Manipulasi tanggal dan waktu sulit dilakukan dengan benar. Selain itu, API Java bawaan sulit digunakan dengan benar - lihat saja aturan untuk bagaimana aritmatika tanggal / waktu API kalender bekerja. Membangun sesuatu di atas ini adalah ide yang buruk daripada menggunakan perpustakaan yang dirancang dengan baik untuk memulai.

5
@adi: Diperbarui - ini masih berlaku, tapi semoga JSR-310 akan menjadi bagian dari Java 8, tapi itu bukan bagian dari Java 7.
Jon Skeet

2
@JonSkeet Ini mungkin harus diperbarui sejak diperkenalkannya java-8
Sionnach733

@ Sionnach733: Saya tidak akan memperbarui semuanya, tapi saya akan menambahkan sesuatu di awal.
Jon Skeet

2
Ada backport dari java.time.*Jawa 6 dan 7: threeten.org/threetenbp
bajingan

24

Nah, kecuali Anda berniat menunggu Java 8, berharap bahwa mereka akan menerapkan API yang lebih baik untuk memanipulasi tanggal dan waktu, ya, tolong, gunakan Joda-Time . Ini menghemat waktu dan menghindari banyak sakit kepala.


Pro dan kontra? Saya tidak pernah menggunakan waktu Joda - akan menarik untuk mendengar apa yang orang suka tentangnya.
Max Stewart

15

Jawabannya adalah: itu tergantung

JODA (dan JSR-310) adalah perpustakaan tanggal / waktu yang berfungsi penuh, termasuk dukungan untuk digunakan dengan beberapa sistem kalender.

Secara pribadi saya menemukan JODA sebagai langkah terlalu jauh dalam hal kompleksitas untuk apa yang saya butuhkan. 2 kesalahan utama (IMHO) di java standar Datedan Calendarkelas adalah:

  1. Mereka bisa berubah
  2. Mereka mencampurkan konsep Tahun-Bulan-Hari dari Waktu-Instan

Meskipun ini ditangani oleh JODA, Anda akan menemukan cukup mudah untuk menggulung kelas Anda sendiri untuk YearMonthDaydan Instant, yang keduanya menggunakan kelas java di bawah tenda untuk perhitungan "kalender" yang sebenarnya. Maka Anda tidak perlu membiasakan diri dengan API>> 100 kelas, mekanisme pemformatan / penguraian yang berbeda dll.

Tentu saja, jika Anda benar-benar membutuhkan representasi kronologis yang berbeda (misalnya bahasa Ibrani) atau ingin dapat mendefinisikan sistem Kalender imajiner Anda sendiri (misalnya untuk permainan yang Anda tulis), mungkin JODA atau JRS-310 cocok untuk Anda. Jika tidak, maka saya akan menyarankan bahwa menggulung sendiri mungkin adalah cara untuk pergi.

Lead spec JSR-310 adalah Stephen Colebourne yang menulis JODA di posisi pertama, sehingga secara logis akan menggantikan JODA.


16
harus tidak akan diciptakan kembali oleh non-spesialis, IMO.
Jon Skeet

6
Saya bukan orang bodoh juga, tapi saya masih punya masalah dengan Java D&T APIs. Mereka sangat mudah disalahgunakan. Alasan mengapa orang lebih mungkin menggunakan Joda dengan benar adalah karena Joda dirancang lebih baik - ini mendorong Anda untuk melakukan hal yang benar.
Jon Skeet

6
Saya memercayai seorang ahli pada diri saya sendiri setiap hari dalam seminggu ketika menyangkut API tanggal / waktu. Ini tidak seperti ini adalah beberapa API pihak ke-3 acak tanpa ada orang lain yang menggunakannya. Argumen "> 100 kelas" adalah orang bodoh, karena Anda jelas tidak perlu mempelajari semuanya.
Jon Skeet

5
Saya kira kita harus setuju untuk berbeda. Setiap tanggal / waktu yang dapat dipercaya ditulis oleh para ahli dan dirancang dengan baik, yang menghindari saya harus melakukan pekerjaan kotor dengan aritmen waktu, dianggap sebagai "harus" dari sudut pandang saya. Selama setahun terakhir saya telah belajar membenci pengukuran waktu manusia dengan penuh gairah.
Jon Skeet

5
Menggulung sendiri ketika Joda ada adalah ide yang sangat mengerikan. Tapi jangan lakukan itu. Memang benar bahwa Joda memiliki banyak kelas yang tidak akan Anda gunakan, tetapi jawabannya cukup sederhana - jangan gunakan yang tidak Anda butuhkan. Ada begitu banyak hal yang bisa salah dengan menulis perpustakaan Anda sendiri dari jenis ini - jumlah upaya yang harus Anda lakukan sangat besar, baik dalam pengembangan dan dalam pengujian. Atau, Anda bisa menambahkan satu perpustakaan. Kemudian, Joda memiliki manfaat tambahan yang mungkin digunakan oleh anggota baru untuk tim Anda sebelumnya, tetapi mereka tidak akan menggunakan perpustakaan asli Anda.
Dawood ibn Kareem

7

Itu semua tergantung pada apa yang Anda lakukan dengan tanggal. Jika Anda hanya bertahan, mereka yang dibangun pada Java Tanggal mungkin akan melakukan semua yang Anda inginkan. Namun jika Anda melakukan manipulasi tanggal waktu yang luas, Anda mungkin lebih baik dengan Joda.


7

Anda harus menggunakan perpustakaan Joda-Time, karena:

  1. Joda-Time mendukung standar ISO 8601 , yang merupakan
    representasi cara tanggal standar .
  2. Menambahkan dan mengurangi hari / bulan / tahun lebih mudah di Joda-Time daripada java.util.date.
  3. Inisialisasi dengan tanggal pemberian jauh lebih mudah di Joda-Time.
  4. Joda-Time mendukung zona waktu juga.
  5. Joda-Time memiliki parsing bawaan yang lebih baik. Tanggal yang salah seperti "2014-02-31" dilemparkan sebagai kesalahan:Exception in thread "main" org.joda.time.IllegalFieldValueException: Cannot parse "2014-02-31": Value 31 for dayOfMonth must be in the range [1,28].

Anda mungkin menyukai halaman ini untuk lebih jelasnya: http://swcodes.blogspot.com/

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.