Boş Sorun: JSpecify ile Java'da daha iyi boş denetimler
Bir yıl önce Java'daki boş kontroller hakkında zaten yazmıştım. Davranışına ilişkin ek açıklamalarla birlikte yöntem ve yapıcı parametrelerini dahil etmek hala mantıklıdır. null (Örneğin @NonNull). Ancak JSpecify'ın 1.0 sürümü yakın zamanda piyasaya sürüldüğü için destek artık önemli ölçüde iyileşti. Konuyu güncellemek için kullanmak istiyorum.
Duyuru
Hendrik Ebbers (@hendrikEbbers) bir Java Şampiyonudur, JCP Uzman Grubunun üyesidir ve birçok kez JavaOne Rockstar Konuşmacısı olarak tanınmıştır. Hendrik, şirketi Open Elements ile şu anda Hedera Hashgraph'ın tasarlanmasına ve hizmetlerinin halka sunulmasına yardımcı oluyor. Hendrik, JUG Dortmund ve Cyberland'in kurucu ortağıdır ve dünya çapında Java konusunda konuşmalar ve atölye çalışmaları düzenlemektedir. “JavaFX 8 Kontrollerinde Uzmanlaşmak” adlı kitabı 2014 yılında Oracle Press tarafından yayımlandı. Hendrik, JakartaEE veya Eclipse Adoptium gibi açık kaynaklı projeler üzerinde aktif olarak çalışıyor. Hendrik, AdoptOpenJDK TSC ve Eclipse Adoptium WG üyesidir.
JSpecify için kapsamlı işbirliği
JSpecify, önceki sıfır yönetimli açıklama satıcılarının nihayet kullanılabilir bir standart tanımlamak için bir araya geldiği açık kaynaklı bir projedir. Bunlar, diğerlerinin yanı sıra Google, JetBrains, Meta, Microsoft ve Oracle'ı içerir. JSpecify, Java modül sistemindeki tam teşekküllü bir modüldür, kendine ait hiçbir bağımlılığı yoktur ve yalnızca dört ek açıklamayla, yönetmek için modern bir Java projesinde ihtiyacınız olan her şeyi sağlar. null parametreleri belirtmek için. Ek açıklamaları kullanan örnek kod şöyle görünebilir:
static @Nullable String emptyToNull(@NonNull String x) {
return x.isEmpty() ? null : x;
}
static @NonNull String nullToEmpty(@Nullable String x) {
return x == null ? "" : x;
}
Ek kod örnekleri JSpecify kullanım kılavuzunda bulunabilir.
Ancak, yalnızca JSpecify ek açıklamasını eklemenin çok az etkisi vardır. Derleyici kodu çevirmeye devam eder null ile birine @NonNull-açıklamalı parametre ve çevrilmiş kod, çalışma zamanında otomatik olarak bir istisna atmaz.
Ek açıklamaların avantajları
Ek açıklamaların avantajı, geliştirme ortamlarıyla etkileşimde diğer hususların yanı sıra görülebilir. IntelliJ, ek açıklamaları tespit edebilir ve ek açıklamaları ihlal eden kod için uyarıları veya hataları görüntüleyebilir. Güvende olmak ve bu tür sorunlarla kodlanmaya hiç izin vermemek istiyorsanız ek araçlar kullanabilirsiniz. Uber tarafından geliştirilen açık kaynaklı NullAway aracı, bu ek açıklamaları oluşturma sırasında kontrol edebilir ve ek açıklama tanımı karşılanmazsa hatalar üretebilir. Bunu Gradle veya Maven yapınıza eklerseniz derleme sırasında otomatik olarak bir hata oluşacaktır:
error: [NullAway] passing @Nullable parameter 'null' where @NonNull is required
myMethod(null);
^
Bu araç zinciriyle kodunuzu çok daha sağlam ve NullPointerExceptionçalışma zamanında kaçının.
Her derde deva değil
Artık bu konuda endişelenmenize gerek yok NullPointerExceptions Yapmak? Maalesef o kadar basit değil. Bu önlemler yalnızca kodunuzu kontrol edebilir. Bu tür ek açıklamaları kullanmayan bağımlılıklarınız varsa, bunu parametre olarak kullanıp kullanamayacağınızı bilemezsiniz. null bulaşabilir mi ve bu hangi davranışı tetikler? Bu nedenle değişkenleri farklı yerlere ayarlamak hala önemlidir. null kontrol etmek için.
Kitaplıklar veya başka projelerden çağrılan kodlar geliştirenler, kullanıcıların tanımlanmış kurallara ve bunlardan birine saygı göstereceğini garanti edemez. @NonNull Aslında belirtilen hiçbir parametre yok null devretmek. Bu nedenle, ister kendi bağımlılıklarınızda ister genel bir API'de olsun, kodunuzun bağlamından ayrılırken her zaman boş denetimler yapmanız önemlidir.
Bu OpenJDK'dan java.util.Objects.requireNonNull(obj, message) tercih edilen yöntem olmaya devam ediyor. Her zaman anlamlı istisnalar oluşturmak için, mesaj parametresiyle birlikte varyantı kullanmalısınız, aksi takdirde sistem… NullPointerException mesaj olmadan. Herkese açık bir API için her şey şöyle görünür:
public void setName(@NonNull String name) {
this.name = Objects.requireNonNull(name, “name must not be null”);
}
Performansın kritik olduğu bir ortamda çalışan herkes, kontroller için kendi yöntemlerini kullanmaktan kaçınmalıdır. JIT derleyicisi bunu halleder Objects.requireNonNull(...) ek açıklama yoluyla @ForceInline özellikle performansı ve yığın boyutunu optimize etmek için tüm yöntem çağrılarını doğrudan çağıran yönteme (satır içi) yerleştirir.
En iyi uygulamalara ve standarda doğru sonraki adımlar
Java topluluğunun bugünkü konumuna ulaşması ve sıfır yönetim açıklamasına sahip temiz, kullanışlı bir kitaplığa sahip olması uzun zaman aldı. 2006 yılında JSR305 olarak başlayan ve çok çeşitli açıklamalar ve uygulamalarla ilgili birçok sorundan sonra ne yazık ki hızla terk edilen şey, SLF4J (Java için Basit Günlük Tutma Cephesi) gibi fiili bir standarda dönüşebilir.
JSpecify burada açıkça doğru yaklaşımı benimsiyor. NullAway gibi bir araç kendi kendine ortaya çıksa ve kullanım kolaylığı ve en iyi uygulamalarıyla hemen hemen her projenin daha iyi performans göstermesine olanak tanısa harika olurdu. null yüz. Henüz NullAway gibi ek açıklamaları ve araçları kullanmadıysanız denemelisiniz. Şimdi başlamanın tam zamanı.
Not: Bu yazıyı yazdığım sıralarda yeni bir JEP ile OpenJDK'da daha iyi yerel destek duyuruldu. JEP'te tartışılan özelliklerin OpenJDK'nın LTS sürümünde yer alması biraz zaman alacağından, burada açıklanan kaynaklar ve araçlar net bir öneri olmaya devam ediyor. Ancak PEC, güncel bir makalede daha yakından incelenecek kadar yeterli husus sunmaktadır.
(Ben)