JavaDoc'da kullanımdan kaldırıldı mı yoksa reddedildi mi?

11

Bunun için JavaDoc'ta X509Certificate getSubjectDN()şunları belirtir:

Reddedildi , yerine getSubjectX500Principal () getirildi.

Artık kullanılmaması gereken, ancak Denigrated değil yöntemleri için Kullanımdan kaldırılmış görmek için alışkınım. Yorum ile kapatıldığı bu özel durum hakkında bir hata raporu buldum :

Bu bir hata değil. "Kullanımdan kaldırıldı", yalnızca ciddi durumlarda kullanılması amaçlanmaktadır.

Kullanımdan kaldırılmış bir yöntem kullanırken, önerilen genel eylem yöntemi kullanmayı bırakmaktır.

Peki bir yöntem Reddedildi olarak işaretlendiğinde önerilen eylem nedir ?

java terminology javadocs

— Jacob Schoen
kaynak

2

Vay. Cevapları okudum ve teknik olarak doğru olduklarından emin olmakla birlikte, 'Denigrated' kullanmak korkunç bir kelimedir. Sadece 'Cesareti kırılmış' kullanmalılardı. Kod tükürmek gerek yok; bir uyarı yeterlidir.

— Eric King

@Eric King Ben de aynı şekilde hissettim. Daha doğrusu, cesaretiniz kırılırsa, sadece itiraz ettiğini düşünüyorum.

— Jacob Schoen

9

Merriam-Webster tanımı kötülememeyi öneriyor:

1: ününe saldırmak: iftira <rakiplerini aşağılamak>
2: önemini veya geçerliliğini inkar etmek: belittle <başarılarını aşağılamak>

Başka bir ilgili hata, yazılı olanlara dayanarak kötüleyen / küçümsemek javadocs içinde kullanılan ifadelerde niyet maç için göründüğünü - Hata numarası: 4959744 kötülemek X509Certificate.getSubjectDN () & co :

X509CRL içinde X509Certificate ve getIssuerDN yöntemleri getSubjectDN () ve getIssuerDN () () sorunludur . Çok gevşek bir belirtime sahip olan java.security.Principal arabirimini uygulayan belirtilmemiş bir sınıf döndürürler.

GetSubjectDN () ve getIssuerDN () yöntemlerinde ek belirtim olmadığından, uygulamaların isteğe bağlı, uygulamaya özgü bir sınıf döndürmesine izin verilir. Gerçek dünya deneyimi, kodun taşınabilirliği veya güvenilmezliği ile sonuçlanan durumun böyle olduğunu göstermiştir. Uyumluluk nedenleriyle, bu yöntemlerin teknik özellikleri değiştirilemez ve bunlar kurtarılamaz olarak düşünülmelidir.

Değiştirme yöntemleri, iyi tanımlanmış X500Principal sınıfının bir örneğini döndüren getSubjectX500Principal () & co, JDK 1.4'e eklenmiştir. Bu yöntemlerin uygulamaları, bu türden tüm sorunlardan kaçınmak için tasarlanmıştır. Bununla birlikte, yeni yöntemler düşük pozlamadan muzdariptir ve programcılar tanıdık ve daha sezgisel olarak adlandırılmış getSubjectDN () & co yöntemlerini kullanmaya devam etmektedir.

Bunu değiştirmek için eski getSubjectDN () ve getIssuerDN () yöntemleri kullanımdan kaldırılmalıdır. Bu, bu yöntemleri kullanan geliştiricilerin derleme zamanı uyarısı almasını sağlayacaktır.

DEĞERLENDİRME

... Bu durumda kullanımdan kaldırılma uygun görülmedi. Bunun yerine, JavaDoc'a uyarıcı yorumlar eklendi .

Hata ID 5008142'yi okumanın sizi bu "aşağılanmış" şeyler hakkında karıştırdığı gerçeği daha çok onunla ilgilenen geliştiricinin hatası gibi görünüyor.

4959744 hatasını bulmuş ve "yalnızca ciddi durumlarda kullanılması gereken" belirsiz ifadeler yerine değerlendirmelerinde referans vermiş olmalıdırlar. Muhtemelen kopya olarak bile kapanabilirler, "Hata ID 4959744'e göre reddedilme lehine dikkate alınmadı, değerlendirildi ve reddedildi" gibi bir gerekçe .

En azından , hata izleyicilerinin İlgili Raporlar alanında ( Eski bugs.sun.com iirc'de Ayrıca Bkz. Denir ) Hata Kimliği 4959744'e (belki de 4638294 ile birlikte ) başvurabilirler. Bunun yapılmamış olması, ilgili sorunları hiç aramadıklarından şüphelenir.

— tatarcık
kaynak

1

@FrustratedWithFormsDesigner'ın en zor kısmı, sonuçların "bugs.sun.com" a filtrelenmesi için oracle arama sayfasına "denigrated" girme şeklini bulmaktı. Gerisi kolaydı, sadece birkaç arama sonucunu kontrol ettim. "Denigrate" aramak için oldukça iyi bir kelime :)

— gnat

1

Bakın ilkini bulmak için Google'ı kullandım, ama bana başkalarını vermedi. Muhtemelen daha sert görünmeliydim. Teşekkürler

— Jacob Schoen

@jschoen Bence bu senin hatanın o kadar da değil; Bununla ilgili bir cevabı genişlettim

— gnat

4

Biraz daha kazdıktan sonra JDK'da Deprecation adlı bir blog yazısı bulabildim . Temel olarak, Onaylanmadı olarak işaretlenen şeylerin kullanılmasının zararlı olarak kabul edildiğini ve sadece cesaret kırılmış bazı şeylerin olduğunu belirtir.

Birçok özellik sürümü için genel politika, temel JDK bileşenlerinin yalnızca etkin olarak zararlı olmaları durumunda kullanımdan kaldırılmış olarak işaretlenmeleridir. Bir sınıf veya yöntem kullanılması tavsiye edilmezse, genellikle kullanımdan kaldırılmış işareti kazanmak için yeterli değildir.

Şu anda bir öğeyi kullanmaktan vazgeçmek olarak işaretlemenin bir yolu olduğunu, ancak sonunda bunu yapmanın bir yolunu ekleyebileceklerini belirtti.

Bir noktada, bu tür bir tavsiye, daha az zararlı API öğelerinin kullanımı için programlı kontroller yapılmasına izin veren javadoc etiketlerinin ve ek açıklamaların bir kombinasyonuna dayanan, kullanımdan daha az zarar gören "inkâr" tesisiyle resmileştirilebilir.

Denigrated terimini kullanma kararıyla ilgili başka bir şey bulamasam da bu oldukça yakın görünüyor. Ve buna dayanarak, bir geliştiricinin yapması gereken eylemin Kullanımdan Kaldırıldığı ile aynı olduğu , yöntemi kullanmadığı anlaşılıyor .

— Jacob Schoen
kaynak