เลิกใช้แล้วเทียบกับถูกปฏิเสธใน JavaDoc?

11

ใน JavaDoc เพื่อX509Certificate getSubjectDN()ระบุ:

denigratedแทนที่ด้วย getSubjectX500Principal ()

ฉันเคยเห็นเลิกใช้ในวิธีการที่ไม่ควรใช้อีกต่อไป แต่ไม่ได้ลบล้าง ฉันพบรายงานข้อผิดพลาดเกี่ยวกับกรณีนี้โดยเฉพาะซึ่งปิดด้วยความคิดเห็น:

นี่ไม่ใช่ข้อผิดพลาด "เลิกใช้แล้ว" มีไว้เพื่อใช้ในกรณีที่ร้ายแรงเท่านั้น

เมื่อเรากำลังใช้เมธอดที่ถูกคัดค้านการดำเนินการที่แนะนำทั่วไปคือการหยุดใช้เมธอด

ดังนั้นสิ่งที่เป็นปัญหาเมื่อการดำเนินการวิธีการที่ถูกทำเครื่องหมายเป็นdenigrated ?

java terminology javadocs

— Jacob Schoen
แหล่งที่มา

2

ว้าว. ฉันได้อ่านคำตอบแล้วและในขณะที่ฉันมั่นใจว่ามันถูกต้องในทางเทคนิค 'ลบรอย' เป็นคำที่ใช้ไม่ได้ ควรใช้เพียง 'หมดกำลังใจ' ไม่จำเป็นต้องคายรหัส คำเตือนจะพอเพียง

— Eric King เมื่อ

@Eric King ฉันรู้สึกแบบเดียวกัน ฉันคิดมากขึ้นตามเส้นที่ว่าถ้ามันหมดกำลังใจเพียงแค่เลิกมัน

— Jacob Schoen

9

คำจำกัดความ Merriam-Webster ของdenigrateแนะนำ:

1: โจมตีชื่อเสียงของ: ทำให้เสื่อมเสีย <ลบล้างคู่ต่อสู้>
2: ปฏิเสธความสำคัญหรือความถูกต้องของ: ดูแคลน <ลบล้างความสำเร็จของพวกเขา>

ขึ้นอยู่กับสิ่งที่เขียนในข้อผิดพลาดที่เกี่ยวข้องอื่นทำให้เสียชื่อเสียง / ดูแคลนดูเหมือนจะตรงกับความตั้งใจของถ้อยคำที่ใช้ใน javadocs - รหัสข้อผิดพลาด: 4959744 Denigrate X509Certificate.getSubjectDN () & co :

วิธี getSubjectDN () และ getIssuerDN () ใน X509Certificate และ getIssuerDN () ใน X509CRL มีปัญหา พวกเขาส่งคืนคลาสที่ไม่ระบุการใช้อินเตอร์เฟส java.security.Principal ซึ่งมีข้อกำหนดที่หลวมมาก

เนื่องจากไม่มีข้อกำหนดเพิ่มเติมปรากฏอยู่ในเมธอด getSubjectDN () และ getIssuerDN () จึงอนุญาตให้แอปพลิเคชันส่งคืนคลาสเฉพาะที่กำหนดเอง ประสบการณ์ในโลกแห่งความเป็นจริงได้แสดงให้เห็นว่านี่เป็นกรณีที่เกิดจากการไม่สามารถพกพาหรือไม่น่าเชื่อถือของรหัส เพื่อเหตุผลด้านความเข้ากันได้ข้อมูลจำเพาะสำหรับวิธีการเหล่านั้นไม่สามารถเปลี่ยนแปลงได้และจะต้องพิจารณาว่าไม่สามารถเปลี่ยนแปลงได้

เมธอดการแทนที่ getSubjectX500Principal () & co ที่ส่งคืนอินสแตนซ์ของคลาส X500Principal ที่กำหนดไว้อย่างดีถูกเพิ่มใน JDK 1.4 การใช้งานของวิธีการเหล่านั้นได้รับการออกแบบเพื่อหลีกเลี่ยงปัญหาทั้งหมดของการจัดเรียงนี้ อย่างไรก็ตามวิธีการใหม่ที่เกิดจากการเปิดรับแสงน้อยและโปรแกรมเมอร์ยังคงใช้วิธีการที่คุ้นเคยและมีชื่อมากขึ้นอย่างต่อเนื่อง getSubjectDN () & วิธีร่วม

หากต้องการเปลี่ยนสิ่งนี้เมธอด getSubjectDN () และ getIssuerDN () เก่าควรเลิกใช้แล้ว เพื่อให้มั่นใจว่านักพัฒนาที่ใช้วิธีนี้จะได้รับคำเตือนเวลารวบรวม ...

การประเมินผล

... การคัดค้านไม่เหมาะสมในกรณีนี้ แต่ความคิดเห็นเตือนถูกเพิ่มเข้าไปใน JavaDoc

ความจริงที่ว่าการอ่าน Bug ID 5008142 ทำให้คุณสับสนเกี่ยวกับสิ่งที่ "ลบล้าง" นี้ดูเหมือนจะเป็นความผิดพลาดของนักพัฒนาที่จัดการกับมัน

พวกเขาควรจะพบข้อผิดพลาด 4959744 และอ้างถึงในการประเมินผลของพวกเขาแทนคำสั่งที่คลุมเครือ "มีไว้เพื่อใช้ในกรณีที่ร้ายแรงเท่านั้น" พวกเขาอาจจะได้ใกล้เคียงเป็นที่ซ้ำกันด้วยเหตุผลเช่น"เลิกได้รับการพิจารณาประเมินผลและปฏิเสธในความโปรดปรานของการหมิ่นประมาทต่อ Bug ID 4959744"

อย่างน้อยที่สุดพวกเขาสามารถอ้างถึง Bug ID 4959744 (อาจพร้อมกับ4638294 ) ในฟิลด์รายงานที่เกี่ยวข้อง (เรียกว่าดูเพิ่มเติมใน bugs.sun.com iirc เก่า) ของตัวติดตามบั๊ก การทำเช่นนี้ไม่ได้ทำให้ใครสงสัยว่าพวกเขาไม่ได้ค้นหาประเด็นที่เกี่ยวข้องเลย

— ริ้น
แหล่งที่มา

1

@FrustratedWithFormsDesigner ส่วนที่ยากที่สุดคือการคิดวิธีการป้อน "denigrated" ที่หน้าการค้นหาของ Oracle เพื่อผลลัพธ์จะถูกกรองไปที่ "bugs.sun.com" ที่เหลือก็ง่ายฉันแค่ตรวจสอบผลการค้นหาที่หยิบขึ้นมา "ลบรอย" เป็นคำที่ดีงามในการค้นหา :)

— ริ้น

1

เห็นไหมว่าฉันใช้ Google เพื่อค้นหาสิ่งแรก แต่ไม่ได้ให้คนอื่น ฉันน่าจะดูหนักขึ้น ขอบคุณ

— Jacob Schoen

@jschoen ฉันคิดว่านี่ไม่ใช่ความผิดของคุณ ฉันขยายคำตอบให้มากขึ้น

— gnat

4

หลังจากที่บางขุดขึ้นผมก็สามารถที่จะหาบล็อกโพสต์ที่เรียกว่าการเลิกใช้ใน JDK โดยทั่วไประบุว่าสิ่งที่ระบุว่าเลิกใช้แล้วถือว่าเป็นอันตรายที่จะใช้และมีบางสิ่งที่ท้อแท้เพียง

นโยบายทั่วไปสำหรับการเปิดตัวคุณลักษณะหลายอย่างคือองค์ประกอบหลักของ JDK นั้นจะถูกทำเครื่องหมายว่าเลิกใช้แล้วหากเป็นอันตราย หากการใช้คลาสหรือวิธีการเป็นเพียงการแนะนำที่ไม่ดีมักจะไม่เพียงพอที่จะได้รับเครื่องหมายที่เลิกใช้แล้ว

เขากล่าวว่าขณะนี้มีวิธีการทำเครื่องหมายรายการว่าไม่ควรใช้ แต่ในที่สุดพวกเขาอาจเพิ่มวิธีการทำสิ่งนี้

ในบางจุดคำแนะนำประเภทนี้อาจถูกทำเป็นทางการด้วยระบบอำนวยความสะดวก "การลบล้าง" ที่ไม่เป็นอันตรายน้อยกว่าที่คัดค้านโดยใช้การรวมแท็ก javadoc และคำอธิบายประกอบเพื่อให้สามารถตรวจสอบแบบโปรแกรมได้สำหรับการใช้องค์ประกอบ API ที่เป็นอันตรายน้อยเหล่านี้

ในขณะที่ฉันไม่สามารถหาอะไรอย่างอื่นโดยเฉพาะเกี่ยวกับการตัดสินใจที่จะใช้คำว่าdenigratedนี้ดูเหมือนว่าสวยใกล้ และจากสิ่งนี้ดูเหมือนว่าการกระทำที่ผู้พัฒนาควรดำเนินการเหมือนกับเลิกใช้อย่าใช้วิธีนี้

— Jacob Schoen
แหล่งที่มา