2010-12-13 33 views
6

Giao diện AbstractInstant của Joda mở rộng loại thô Comparable, thay vì Comparable<AbstractInstant>, có vẻ như vi phạm Java best practices. Đặc biệt, nó có nghĩa là tôi không thể sử dụng DateTime để parameterize một lớp học như thế này:Tại sao Joda instants mở rộng loại thô Comparable?

class Foo<T extends Comparable<? super T>> { 
    public int ct(T a, T b) { 
     return a.compareTo(b); 
    } 
} 

Đó là sự hiểu biết của tôi như thế này của lớp là hoàn toàn hợp lệ (chắc chắn nó làm việc với đôi, vv). Để có được nó để làm việc với DateTime, tuy nhiên, tôi phải xả rác mã của riêng tôi với các loại nguyên liệu và cảnh báo đàn áp:

@SuppressWarnings("unchecked") 
class Foo<T extends Comparable> { 
    public int ct(T a, T b) { 
     return a.compareTo(b); 
    } 
} 

Có một related question cho thấy một workaround (gói các DateTime trong lớp khác vì mục đích so sánh), nhưng tôi không thấy tại sao điều đó lại cần thiết. Câu hỏi của tôi sau đó là:

  1. Có ai biết tại sao Joda được mở rộng một kiểu thô, hoặc
  2. Đây có phải là một lỗi tôi nên báo cáo với các nhà bảo trì thư viện?
+1

Chỉ cần một lưu ý cho những người đến câu trả lời này gần một năm sau: Joda 2.0 hỗ trợ Generics, do đó, nó giải quyết vấn đề này. – Snekse

Trả lời

2

JodaTime được thiết kế để hoạt động trên Java 1.4 và do đó không sử dụng bất kỳ tính năng Java 5 nào, kể cả Generics.

Vì vậy, có, bạn cần phải thêm công cụ ngăn chặn cảnh báo soạn sẵn trong một số trường hợp.

+1

Nó không phải là "ức chế cảnh báo soạn sẵn". Tôi phải thay đổi giao diện của một lớp chung chung có thể so sánh, vi phạm các thực hành tốt nhất của Java. Nếu tôi không có quyền truy cập vào mã nguồn cho lớp đó, tôi không thể làm được. –

+0

@chrispy: OK, đủ công bằng. Vấn đề là, bạn đang mắc kẹt với nó. – skaffman

+0

heh, đó là sự thật. –

Các vấn đề liên quan