Không dùng nữa so với bị chê bai trong JavaDoc?

Trong JavaDoc cho X509Certificate getSubjectDN()nó nêu:

Bị chê bai , thay thế bằng getSubjectX500Principal ().

Tôi đã từng thấy Deprecated trong các phương thức không nên sử dụng nữa, nhưng không bị chê bai. Tôi đã tìm thấy một báo cáo lỗi về trường hợp cụ thể này khi nó được đóng lại với bình luận:

Đây không phải là một lỗi. "Không dùng nữa" có nghĩa là chỉ được sử dụng trong các trường hợp nghiêm trọng.

Khi chúng ta đang sử dụng một phương thức không dùng nữa , hành động được đề xuất chung là ngừng sử dụng phương thức đó.

Vì vậy, hành động được đề xuất khi một phương thức được đánh dấu là Bị chê bai là gì?

Định nghĩa của Merriam-Webster về sự chê bai gợi ý:

1: để tấn công danh tiếng của: phỉ báng <chê bai đối thủ>
2: phủ nhận tầm quan trọng hoặc giá trị của: coi thường <chê bai thành tích của họ>

Dựa trên những gì được viết trong một lỗi liên quan khác, defame / belittle dường như khớp với mục đích từ ngữ được sử dụng trong javadocs - Bug ID: 4959744 Denigrate X509Cert ve.getSubjectDN () & co :

Các phương thức getSubjectDN () và getIssuerDN () trong X509Certert và getIssuerDN () trong X509CRL có vấn đề . Chúng trả về một lớp không xác định thực hiện giao diện java.security.Principal, có một đặc tả rất lỏng lẻo.

Vì không có đặc tả kỹ thuật bổ sung nào xuất hiện trong các phương thức getSubjectDN () và getIssuerDN (), cho phép các triển khai trả về một lớp cụ thể, thực hiện tùy ý. Kinh nghiệm trong thế giới thực đã chỉ ra rằng đây là trường hợp dẫn đến tính không di động hoặc không đáng tin cậy của mã. Vì lý do tương thích, các thông số kỹ thuật cho các phương thức đó không thể thay đổi và chúng phải được coi là không thể sửa chữa được.

Các phương thức thay thế getSubjectX500Principal () & co trả về một thể hiện của lớp X500Principal được xác định rõ đã được thêm vào trong JDK 1.4. Việc triển khai các phương pháp đó đã được thiết kế để tránh tất cả các vấn đề thuộc loại này. Tuy nhiên, các phương thức mới bị thiếu điều kiện và các lập trình viên tiếp tục sử dụng các phương thức getSubjectDN () & co quen thuộc và có tên trực quan hơn.

Để thay đổi điều này, các phương thức getSubjectDN () và getIssuerDN () cũ không được dùng nữa. Điều đó sẽ đảm bảo rằng các nhà phát triển sử dụng phương pháp này nhận được cảnh báo thời gian biên dịch ....

ĐÁNH GIÁ

... Khấu hao được coi là không phù hợp trong trường hợp này. Thay vào đó, các bình luận thận trọng đã được thêm vào JavaDoc .

Việc đọc Bug ID 5008142 đã khiến bạn bối rối về thứ "bị chê bai" này trông giống như lỗi của nhà phát triển đã xử lý nó.

Họ nên tìm thấy lỗi 4959744 và đưa nó vào đánh giá của họ, thay vì tuyên bố mơ hồ "chỉ được sử dụng trong các trường hợp nghiêm trọng". Họ thậm chí có thể đóng như là bản sao, với lời biện minh như "Khấu hao đã được xem xét, đánh giá và từ chối ủng hộ sự chê bai trên mỗi ID lỗi 4959744" .

Ít nhất họ có thể giới thiệu Bug ID 4959744 (có thể cùng với 4638294 ) trong trường Báo cáo liên quan (được gọi là Xem thêm trong lỗi cũ.sun.com iirc) của trình theo dõi lỗi của họ. Rằng điều này chưa được thực hiện khiến người ta nghi ngờ rằng họ không tìm kiếm các vấn đề liên quan.

Sau khi đào sâu thêm, tôi đã có thể tìm thấy một bài đăng trên blog có tên là Khấu hao trong JDK . Về cơ bản nó khẳng định rằng mọi thứ đánh dấu Deprecated được coi là có hại được sử dụng, và rằng có một số điều mà chỉ đơn giản là không được khuyến khích.

Chính sách chung cho một số bản phát hành tính năng là các thành phần JDK cốt lõi chỉ được đánh dấu là không dùng nếu chúng có hại tích cực. Nếu việc sử dụng một lớp học hoặc phương thức chỉ là không đúng đắn, điều đó thường không đủ để kiếm được điểm không dùng nữa.

Ông nói rằng hiện tại có một cách để đánh dấu một mục là không được khuyến khích sử dụng, nhưng cuối cùng họ có thể thêm một cách để làm điều này.

Tại một số điểm, loại lời khuyên này có thể được chính thức hóa với một cơ sở "chê bai" ít gây hại hơn là dựa trên sự kết hợp giữa các thẻ javadoc và chú thích để cho phép kiểm tra theo chương trình để sử dụng các yếu tố API ít gây hại này.

Mặc dù tôi không thể tìm thấy bất cứ điều gì khác cụ thể về quyết định sử dụng thuật ngữ Khước từ nhưng điều này có vẻ khá gần. Và dựa trên điều này, có vẻ như hành động mà nhà phát triển nên thực hiện giống như Không dùng nữa , không sử dụng phương thức này.