Sorunun geçmişi.
Java 5, parametreli türleri tanıttığında, dilin önceki jeneriklerden önce derlenmiş eski kod ile ikili uyumluluğu korumak için tür silinmesini benimsediği anlamına geliyor. Bu tasarım kararı, JVM seviyesinde, tüm jenerik tür parametrelerinin ham sınırlarıyla - genellikle Object - değiştirildiği ve gerçek tür argümanlarının çalışma zamanı izinin bırakılmadığı anlamına gelir. Sonuç olarak, bir somut sınıf Comparable<String> gibi bir arayüzü uyguladığında, compareTo'nun silinmiş imzası compareTo(Object) hâline gelirken, uygulayan sınıf compareTo(String) olarak tanımlanır. Müdahale olmadan, JVM bu yöntemleri bağlamakta başarısız olur ve bunları ayrık varlıklar olarak değerlendirir, çok biçimli geçersiz kılmalara ilişkin değildir.
Sorun.
Temel sorun, derlenmiş müşteri kodu ile uygulayan sınıf arasında ikili uyumsuzluk olarak ortaya çıkar. Jenerik arayüze karşı derlenmiş müşteri kodu, ham imza ile bir yöntemi bekler (örneğin, compareTo(Object)), ancak uygulayan sınıf yalnızca belirli imzayı sağlar (örneğin, compareTo(String)). Çalışma zamanında, JVM yöntem dağıtımını sabit havuzundaki tanımlayıcılar temelinde gerçekleştirir; eğer tanımlayıcı (Ljava/lang/Object;)I somut uygulamayla eşleşmezse, sanal makine bir AbstractMethodError fırlatır veya tamamen yanlış bir yöntemi çağırır. Bu boşluk, jenerik arayüzler için gerçek çok biçimli davranışı engeller ve silinmiş sözleşmeyi belirli uygulama ile uzlaştırmak için bir mekanizmayı zorunlu kılar.
Çözüm.
Java derleyicisi, uygulayan sınıf içinde silinmiş ham imzaya sahip bir sentetik köprü yöntemi üreterek bu durumu çözer. Bu köprü yöntemi, byte kodundaki ACC_BRIDGE ve ACC_SYNTHETIC erişim bayrakları ile işaretlenir; bu, derleyici tarafından üretildiğini ve kaynak kodunda mevcut olmadığını gösterir. Köprü yöntemi, argümanını belirli türe güvenilmez bir şekilde dönüştürerek ve gerçek yöntemi çağırarak, gerçek uygulamaya yönlendirir. Bu yönlendirme, JVM yöntem çözümleme algoritmasının çalışma zamanında eşleşen bir tanımlayıcı bulmasını sağlar, köprü içindeki dönüştürme, derleme zamanında doğrulanan tür güvenliği kısıtlamalarını zorlar.
interface Node<T> { void setData(T data); } class StringNode implements Node<String> { @Override public void setData(String data) { System.out.println(data.toLowerCase()); } }
Yukarıdaki örnekte, derleyici StringNode içinde public void setData(Object data) adında bir sentetik yöntem üretmektedir ve argümanı String olarak dönüştürüp gerçek setData(String) yöntemini çağırır.
Sorun tanımı.
Bir içerik yönetim sistemi için modüler bir eklenti mimarisi tasarlarken, eklentilerin UserLoginEvent veya DocumentSaveEvent gibi olaylar için tür-spesifik işleyiciler uygulayabileceği bir EventHandler<T> arayüzüne ihtiyacımız vardı. Ham türler ile çalışan ilk prototipler işe yaradı, ancak jeneriklere geçiş yapmak, dinamik olarak yüklenen eklenti sınıflarının, olay otobüsü jenerik arayüzü üzerinden olayları dağıtmaya çalışırken AbstractMethodError'u bazen tetiklediğini gösterdi. Bu sorun yalnızca belirli JDK sürümleri ve karmaşık sınıf yükleyici hiyerarşileri ile ortaya çıkıyor, bu da sürekli olarak yeniden üretmeyi zorlaştırıyordu.
Farklı çözümler değerlendirildi.
Bir yaklaşım, jenerikleri tamamen ortadan kaldırmak ve her işleyici uygulamasında manual instanceof kontrolleri ile ham Object türleri kullanmaktı. Bu strateji, farklı JDK sürümleri arasında geniş bir uyumluluk sağlıyordu ve sentetik yöntem karmaşalarını tamamen önlüyordu. Ancak, bu, derleme zamanı tür güvenliğini feda ediyordu ve geliştiricilerin çalışma zamanı sırasında ClassCastException'a eğilimli olan boilerplate dönüştürme mantığını yazmalarını zorunlu kılıyordu. Olay türleri sayısının artmasıyla bakım yükü önemli ölçüde arttı ve kod, gerçek tür hatalarını gizleyen kontrol edilmeyen uyarılarla dağınık hale geldi.
Diğer bir alternatif, çalışma zamanında java.lang.reflect.Proxy kullanarak dinamik proxyler oluşturmaktı; bu, yöntem çağrılarını kesip otomatik olarak tür uyumunu sağlamaktaydı. Bu çözüm, eklenti yazarları için tür güvenliğini korurken, silinmiş uyumsuzluğu içsel olarak ele aldı. Ne yazık ki, proxy yaklaşımı, yansıma ve yöntem çağrısı gecikmeleri nedeniyle önemli bir performans yükü getirdi ve yığında ek düzeyler ekleyerek hata ayıklamayı karmaşıklaştırdı. Ayrıca, etkinlik otobüsünün proxy örnekleri ile gerçek eklenti örnekleri arasında karmaşık eşleme mantığını sürdürmesini zorunlu kıldığı için bellek kullanımını artırdı.
Seçilen çözüm, tüm eklenti arayüzlerinin doğru bir şekilde jenerik olduğundan ve uygulama sınıflarının Java 5+ derleyicisi ile derlendiğinden emin olarak derleyicinin köprü yöntem üretimini benimsemekteydi. Yükledikleri derlenmiş eklenti sınıflarında köprü yöntemlerinin mevcut olduğunu doğrulamak için ASM kullanarak byte kodu doğrulama testleri ekledik. Bu yaklaşım, çalışma zamanında sıfır yük, tam tür güvenliğini korudu ve standart Java derleme uygulamalarıyla uyumlu hale geldi; özel sınıf yükleyici manipülasyonlarını gerektirmedi.
Hangi çözüm seçildi ve neden.
Derleyicinin köprü yöntemini üretme yaklaşımını seçtik çünkü bu, çalışma zamanı karmaşıklığına neden olmadan derleyicinin garantili davranışını kullanıyor. Manuel dönüştürmenin aksine, çağrı yerinde tür kısıtlamalarını sentetik köprünün dönüştürmesiyle uygulamaktadır; eğer tür güvenliği ihlal edilirse hızlı bir şekilde ClassCastException ile başarısız olur. Dinamik proxylerle karşılaştırıldığında, yansıma gecikmesini ortadan kaldırır ve temiz, yorumlanabilir yığın izlerini korur. Bu çözüm, çalışma zamanı yükünü en aza indirirken derleme zamanı doğrulamasını maksimuma çıkarmayı hedefledi.
Sonuç.
Doğru jenerik tanımlarını uyguladıktan ve derleme zamanı byte kodu doğrulamasını ekledikten sonra, AbstractMethodError olayları tamamen sona erdi. Eklenti geliştiricileri, EventHandler<UserLoginEvent> uygularken, etkinlik otobüsünün olayları doğru yönlendireceğinden emin olabiliyordu, manuel dönüştürme olmadan. Mimari, elliden fazla ayrık olay türünü destekleyecek şekilde genişleyebildi ve performans profillemesi, sentetik yöntemlerin herhangi bir ölçülebilir yük getirmediğini doğruladı.
Yansıma köprü yöntemini gerçek uygulama yönteminden nasıl ayırır ve bu ayrım dinamik olarak yöntemleri çağırırken neden önemlidir?
java.lang.reflect.Method kullanılırken, adaylar genellikle getDeclaredMethods()'in yalnızca kaynak seviyesindeki yöntemleri döndüğünü varsayar. Gerçekte, bu sentetik köprü yöntemlerini de içerir ve bu durum filtrelenmediği takdirde yinelemeli çağrılara veya yanlış mantığa yol açabilir. Method sınıfı, bu derleyici tarafından üretilen varlıkları belirlemek için isBridge() ve isSynthetic() kurallarını sağlar. Bu bayrakları kontrol etmemek, köprü yönteminin yansıtılarak çağrılması durumunda sonsuz yinelemeye neden olabilir, çünkü köprü yöntem, hedef yönteme yönlendirir; bu yöntem de muhtemelen yansıtma yoluyla bir döngüde çağrılır.
Neden, jenerik olmayan sınıflardaki değişen döndürme türleri de köprü yöntemleri üretmektedir ve bu, synchronized anahtarıyla nasıl etkileşim göstermektedir?
Adaylar sıklıkla köprü yöntemlerinin yalnızca jeneriklere özgü olmadığını; aynı zamanda, döndürme türlerini daraltarak geçersiz kılınan yöntemlerde de ortaya çıktığını gözden kaçırıyorlar (değişen döndürmeler). Örneğin, bir üst sınıf Number döndürürse ve bir alt sınıf bunu Integer döndürmek için geçersiz kılarsa, Number döndüren bir köprü yöntemi üretilir. Kritik bir detay, synchronized anahtarının asla köprü yönteme kopyalanmadığıdır çünkü JVM kilidi köprünün çerçevesinde kazanılacak, bu da gerçek uygulama ile olan istemleri kırma potansiyeline sahiptir. Bunu anlamak, köprü yöntemlerinin kendi senkronizasyon anlamlarına sahip basit yönlendirme parçaları olduğunu bilmekle gereklidir.
Bir jenerik arayüz yönteminin varargs parametresi ile geçersiz kılınması durumunda ne olur ve köprü yöntemi byte kodu seviyesinde dizi ile varargs ayrımını nasıl ele alır?
Bu senaryo, silinmiş imzanın bir dizi türü (Object[]) kullandığı ve uygulamanın varargs kullandığı karmaşık bir köprü oluşturur. Derleyici, varargs yöntemini çağıran Object[] alanını kabul eden bir köprü yöntemi üretir. Adaylar, varargs yöntemlerinin byte kodu seviyesinde dizi parametrelerine derlendiğini gözden kaçırmakta; bu nedenle, köprü, gerçek yöntemle tanımcı açısından aynı görünmektedir; derleyicinin bunları ayırt etmesi veya ACC_VARARGS bayrağını kullanması için ek bir mantık üretmesi gerekmektedir. Bunu yanlış anlamak, dizisel argümanları gösteren yığın izlerinde olduğu gibi veya tanımcı eşleşme karmaşıklıkları nedeniyle MethodHandle kullanarak böyle yöntemleri çağırırken kafa karışıklığına yol açar.