Sorunun Cevabı

Tarih. Java 9'dan önce, yansıma setAccessible(true) ile erişim belirleyicilerini keyfi olarak aşabiliyordu ve kapsüllemeyi istediği gibi ihlal edebiliyordu. Java Platform Modül Sistemi (JPMS), modüllerin dahili paketlerine derin yansımalar için izin vermesi gerektiği durumlarda varsayılan olarak güçlü bir kapsülleme sağlamaktadır.

Sorun. Bir modüldeki kod, başka bir modülün paketindeki halka kapalı bir alana MethodHandles veya temel yansıma ile erişmeye çalıştığında, JVM titiz bir erişilebilirlik kontrolü gerçekleştirir. Bu doğrulama, hedef paketin arayan modüle açık bir şekilde açıldığını garanti eder. Bu izin olmadan, JVM bir InaccessibleObjectException (veya eski yansıma için IllegalAccessException) fırlatır; bu durum bir SecurityManager kurulmuş olsa bile veya alan VarHandle aracılığıyla erişilse bile geçerlidir.

Çözüm. Modül, module-info.java dosyasındaki opens package.name [to specific.module]; ifadesini açıklamalıdır veya uygulama, --add-opens source.module/package.name=target.module bayrağı ile başlatılmalıdır. Bu direktif, modülün iç erişilebilirlik grafiğini dinamik olarak değiştirerek hedef modülü bu paketin özel üyeleri üzerinde derin yansıma yapma yetkisine sahip modüller setine ekler.

// Modül: app.core (module-info.java)
module app.core {
    // Paket com.app.internal açılmamıştır
    exports com.app.api;
}

// Modül: framework.inject
public class Injector {
    public void inject(Object target) throws Throwable {
        MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(
            target.getClass(), 
            MethodHandles.lookup()
        );
        // --add-opens olmadan InaccessibleObjectException fırlatılır
        VarHandle handle = lookup.findVarHandle(
            target.getClass(), 
            "secretField", 
            String.class
        );
        handle.set(target, "injected");
    }
}

Gerçek Hayattan Bir Durum

Bir geliştirme ekibi, monolitik Spring tabanlı uygulamalarını Java Modül Sistemi'ne taşımış, kod tabanını ana iş mantığı modülüne (app.core) ve ayrı bir bağımlılık enjeksiyon çerçevesi modülüne (framework.inject) ayırmıştır. Dağıtımdan hemen sonra uygulama, çerçevenin app.core'nün dahili com.app.internal paketindeki özel alanlara yapılandırma değerleri enjekte etmeye çalışırken bir InaccessibleObjectException ile çökmüştür.

Üç potansiyel mimari çözüm değerlendirilmiştir. İlk yaklaşım, tüm enjekte edilebilir sınıfların app.core içindeki dışa aktarılmış paketlere yerleştirilmesini içermekteydi. Bu, hemen erişim ihlalini çözse de, iç uygulama detaylarının diğer modüllere açılmasıyla kapsülleme ilkelerini temelinden ihlal edecekti, böylece bakım yükünü artıracak ve gelecekteki güvenlik denetimleri için saldırı yüzeyini genişletecekti. İkinci çözüm, --add-exports JVM argümanını kullanarak iç paketleri çerçeve modülüne açmayı öneriyordu. Ancak, --add-exports yalnızca derleme zamanı ve çalışma zamanı için herkese açık türlerin görünürlüğünü sağlarken, özel üyeler üzerindeki derin yansımaya izin vermemekte, dolayısıyla Spring'in alan enjeksiyon mekanizmaları için yetersiz kalmaktaydı. Üçüncü seçenek, hedeflenen komut satırı argümanı --add-opens app.core/com.app.internal=framework.inject'i kullanmaktaydı. Bu yaklaşım, tüm diğer modüller için katı kaynak düzeyi kapsüllemeyi korurken, yalnızca enjeksiyon çerçevesine özel iç paket üzerine derin yansıma için gerekli yetkileri vermekteydi.

Ekip sonunda üçüncü seçeneği seçti, gerekli --add-opens direktiflerini dağıtım betiklerine ve Docker yapılandırmalarına belgeledi. Bu çözüm, modül sistemi geliştirirken bütünlüğü korudu ve çerçevenin doğru bir şekilde çalışmasına izin vererek, açıkça kontrol edilen erişim sınırları ile başarılı bir geçiş sağladı.