Đặc điểm chung
a) Cả hai thư viện đều sử dụng các loại bất biến. Joda-Time cũng cung cấp các loại đột biến bổ sung như MutableDateTime.
b) Hơn nữa: Cả hai thư viện đều được truyền cảm hứng từ nghiên cứu thiết kế "TimeAndMoney" từ Eric Evans hoặc ý tưởng từ Martin Fowler về phong cách điều khiển tên miền để họ cố gắng ít nhiều cho phong cách lập trình trôi chảy (mặc dù không phải lúc nào cũng hoàn hảo ;-)).
c) Với cả hai thư viện, chúng tôi nhận được một loại ngày theo lịch thực (được gọi LocalDate), loại thời gian tường thực (được gọi LocalTime) và thành phần (được gọi LocalDateTime). Đó là một chiến thắng rất lớn so với cũ java.util.Calendarvà java.util.Date.
d) Cả hai thư viện đều sử dụng cách tiếp cận tập trung vào phương thức, nghĩa là họ khuyến khích người dùng sử dụng getDayOfYear()thay vì get(DAY_OF_YEAR). Điều này gây ra rất nhiều phương thức bổ sung so với java.util.Calendar(mặc dù sau này không an toàn về kiểu do sử dụng quá nhiều ints).
Hiệu suất
Xem câu trả lời khác của @ OO7 chỉ vào phân tích của Mikhail Vorontsov mặc dù điểm 3 (bắt ngoại lệ) có thể đã lỗi thời - hãy xem lỗi JDK này . Hiệu suất khác nhau (có lợi cho chung của JSR-310 ) chủ yếu là do việc triển khai nội bộ của Joda-Time luôn sử dụng thời gian dài nguyên thủy giống như thời gian của máy (tính bằng mili giây).
Vô giá trị
Joda-Time thường sử dụng NULL làm mặc định cho múi giờ hệ thống, ngôn ngữ mặc định, dấu thời gian hiện tại, v.v. trong khi JSR-310 hầu như luôn từ chối các giá trị NULL.
Độ chính xác
JSR-310 xử lý độ chính xác nano giây trong khi Joda-Time bị giới hạn ở độ chính xác mili giây .
Các lĩnh vực được hỗ trợ:
Tổng quan về các trường được hỗ trợ trong Java-8 (JSR-310) được đưa ra bởi một số lớp trong gói tạm thời (ví dụ ChronoField và WeekFields ) trong khi Joda-Time khá yếu trên khu vực này - xem DateTimeFieldType . Sự thiếu hụt lớn nhất của Joda-Time là ở đây sự vắng mặt của các lĩnh vực liên quan đến tuần địa phương. Một đặc điểm chung của cả hai thiết kế triển khai trường là cả hai đều dựa trên các giá trị của loại dài (không có loại nào khác, thậm chí không có enum).
Enum
JSR-310 cung cấp các enum như DayOfWeekhoặc Monthtrong khi Joda-Time không cung cấp điều này bởi vì nó chủ yếu được phát triển trong những năm 2002-2004 trước Java 5 .
API khu vực
a) JSR-310 cung cấp nhiều tính năng múi giờ hơn Joda-Time. Latter không thể mang lại quyền truy cập theo chương trình vào lịch sử của các chuyển đổi bù múi giờ trong khi JSR-310 có khả năng thực hiện điều này.
b) Để biết thông tin của bạn: JSR-310 đã chuyển kho lưu trữ múi giờ bên trong của nó sang một vị trí mới và một định dạng khác. Thư mục thư viện cũ lib / zi không còn tồn tại nữa.
Điều chỉnh so với tài sản
JSR-310 đã giới thiệu TemporalAdjustergiao diện như một cách chính thức để ngoại hóa các tính toán và thao tác tạm thời, đặc biệt đối với thư viện hoặc người viết khung, đây là một cách dễ dàng và tương đối dễ dàng để nhúng các phần mở rộng mới của JSR-310 (một loại tương đương với trình trợ giúp tĩnh lớp học trước đây java.util.Date).
Tuy nhiên, đối với hầu hết người dùng, tính năng này có giá trị rất hạn chế vì gánh nặng để viết mã vẫn thuộc về người dùng. Các giải pháp tích hợp dựa trên nhận thức mới TemporalAdjusterkhông nhiều, hiện tại chỉ có lớp người trợ giúp TemporalAdjustersvới một bộ thao tác giới hạn (và enum Monthhoặc các loại thời gian khác).
Joda-Time cung cấp gói trường nhưng thực tế đã cho thấy bằng chứng cho thấy việc triển khai trường mới rất khó mã hóa. Mặt khác, Joda-Time cung cấp các thuộc tính được gọi là làm cho một số thao tác dễ dàng và thanh lịch hơn nhiều so với trong JSR-310, ví dụ property.withMaximumValue () .
Hệ thống lịch
JSR-310 cung cấp thêm 4 hệ thống lịch. Điều thú vị nhất là Umalqura (được sử dụng ở Ả Rập Saudi). 3 người còn lại là: Minguo (Đài Loan), Nhật Bản (chỉ có lịch hiện đại kể từ năm 1871!) Và ThaiBuddhist (chỉ đúng sau năm 1940).
Joda-Time cung cấp lịch Hồi giáo dựa trên cơ sở tính toán - không phải là lịch dựa trên tầm nhìn như Umalqura. Thái-Phật cũng được cung cấp bởi Joda-Time trong một hình thức tương tự, Minguo và tiếng Nhật không. Mặt khác, Joda-Time cũng cung cấp lịch coptic và ethiopic (nhưng không có bất kỳ sự hỗ trợ nào cho việc quốc tế hóa).
Thú vị hơn đối với người châu Âu: Joda-Time cũng cung cấp lịch Gregorian , Julian và hỗn hợp gregorian-julian. Tuy nhiên, giá trị thực tế cho các tính toán lịch sử thực tế bị hạn chế vì các tính năng quan trọng như năm bắt đầu khác nhau trong lịch sử ngày không được hỗ trợ (cùng một lời chỉ trích là hợp lệ đối với cũ java.util.GregorianCalendar).
Lịch khác như tiếng Hebrew hoặc Ba Tư hay Ấn Độ giáo là hoàn toàn mất tích trong cả hai thư viện.
Ngày kỷ nguyên
JSR-310 có lớp JulianFields trong khi Joda-Time (phiên bản 2.0) cung cấp một số phương thức trợ giúp trong lớp DateTimeUtils .
Đồng hồ
JSR-310 không có giao diện (lỗi thiết kế) mà là một lớp trừu tượng java.time.Clockcó thể được sử dụng cho bất kỳ phép tiêm phụ thuộc đồng hồ nào. Joda-Time cung cấp giao diện MillisProvider và một số phương thức trợ giúp trong DateTimeUtils thay thế. Vì vậy, cách này Joda-Time cũng có khả năng hỗ trợ các mô hình điều khiển thử nghiệm với các đồng hồ khác nhau (chế nhạo, v.v.).
Số học thời lượng
Cả hai thư viện đều hỗ trợ tính toán khoảng cách thời gian trong một hoặc nhiều đơn vị thời gian. Tuy nhiên, khi xử lý thời lượng một đơn vị, kiểu JSR-310 rõ ràng là đẹp hơn (và dựa trên dài thay vì sử dụng int):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
Thời gian Joda => int days = DAYS.daysBetween(date1, date2).getDays();
Xử lý nhiều đơn vị thời lượng cũng khác nhau. Ngay cả các kết quả tính toán cũng có thể khác nhau - hãy xem vấn đề Joda-Time đã đóng này . Trong khi JSR-310 sử dụng một cách tiếp cận rất đơn giản và hạn chế để chỉ sử dụng các lớp Period(thời lượng dựa trên năm, tháng và ngày) và Duration(dựa trên giây và nano giây), Joda-Time sử dụng cách thức tinh vi hơn để sử dụng lớp PeriodTypeđể kiểm soát trong đó các đơn vị thời lượng (Joda-Time gọi là "Thời gian") sẽ được thể hiện. Trong khiPeriodType-API bằng cách nào đó lúng túng khi sử dụng một cách tương tự không được cung cấp bởi JSR-310. Đặc biệt, vẫn chưa có khả năng trong JSR-310 để xác định thời lượng ngày và thời gian hỗn hợp (ví dụ dựa trên ngày và giờ). Vì vậy, được cảnh báo nếu di chuyển từ thư viện này sang thư viện khác. Các thư viện trong cuộc thảo luận không tương thích - mặc dù có cùng một tên lớp.
Khoảng
JSR-310 không hỗ trợ tính năng này trong khi Joda-Time có hỗ trợ hạn chế. Xem thêm câu trả lời SO này .
Định dạng và phân tích cú pháp
Cách tốt nhất để so sánh cả hai thư viện là xem các lớp có tên bằng nhau DateTimeFormatterBuilder (JSR-310) và DateTimeFormatterBuilder (Joda-Time). Biến thể JSR-310 mạnh hơn một chút (cũng có thể xử lý bất kỳ loại TemporalFieldcung cấp nào mà người triển khai trường đã quản lý để mã hóa một số điểm mở rộng như giải quyết () ). Tuy nhiên, sự khác biệt quan trọng nhất - theo ý kiến của tôi:
JSR-310 có thể phân tích tên múi giờ tốt hơn nhiều (ký hiệu mẫu định dạng z) trong khi Joda-Time hoàn toàn không thể làm điều này trong các phiên bản trước đó và bây giờ chỉ trong một cách rất hạn chế.
Một ưu điểm khác của JSR-310 là hỗ trợ các tên tháng độc lập, quan trọng trong các ngôn ngữ như tiếng Nga hoặc tiếng Ba Lan, v.v. Joda-Time không có quyền truy cập vào các tài nguyên đó - ngay cả trên các nền tảng Java-8.
Cú pháp mẫu trong JSR-310 cũng linh hoạt hơn so với Joda-Time, cho phép các phần tùy chọn (sử dụng dấu ngoặc vuông), được định hướng nhiều hơn theo tiêu chuẩn CLDR và cung cấp phần đệm (ký hiệu chữ p) và nhiều trường hơn.
Mặt khác, cần lưu ý rằng Joda-Time có thể định dạng thời lượng bằng cách sử dụng periodFormatter . JSR-310 không thể làm điều này.
Hy vọng tổng quan này giúp. Tất cả các thông tin thu thập được chủ yếu ở đó do những nỗ lực và điều tra của tôi về cách thiết kế và thực hiện một thư viện ngày giờ tốt hơn (không có gì là hoàn hảo).
Cập nhật từ 2015-06-24:
Trong khi đó, tôi đã tìm thấy thời gian để viết và xuất bản một tổng quan dạng bảng cho các thư viện thời gian khác nhau trong Java. Các bảng cũng chứa một so sánh giữa Joda-Time v2.8.1 và Java-8 (JSR-310). Nó chi tiết hơn bài này.