Java Kodunu AI İçin Obfuscate Etmeye Çalıştım, İşte Kırılanlar
Java kodunu AI'ya göndermeden önce obfuscate etme denemesi, Spring Data, JPA ve Lombok'un isim bağımlılıklarını gün yüzüne çıkardı.
Bir sözleşme maddesi kodlarını AI araçlarına göstermeyi yasaklayınca, bir geliştirici basit bir çözüm denedi: Java kaynak kodundaki sınıf, metot ve alan isimlerini rastgele hash'lerle değiştirip AI'ya öyle göndermek, sonra sonucu geri çevirmek. Fikir teoride birkaç günlük bir iş gibi görünse de pratikte haftalarca sürdü, çünkü isimlendirme Java'da salt bir etiket değil.
Sorun art arda katmanlar halinde ortaya çıktı. Spring Data repository metotları (findByActiveTrue gibi) aslında metot adından SQL üreten bir sözleşme; adı değiştirmek uygulamayı çökertiyor. JPQL sorguları entity sınıf ve alan adlarına referans veriyor, native SQL sorguları ise tablo/sütun adlarına dokunmamalı. Lombok, alan adlarından derleme zamanında getter/setter üretiyor; bir alanı yeniden adlandırmak tüm kod tabanındaki çağrı noktalarını da senkron güncellemeyi gerektiriyor. Buna Jackson JSON anahtarları, Bean Validation mesaj şablonları, @ConfigurationProperties YAML eşlemeleri, reflection string'leri ve OpenAPI şemaları da eklenince toplam sekiz ayrı 'framework algılayıcısı' yazmak gerekti.
Sonuçta işleyen çözüm, isim değiştirmeden önce projeyi framework anotasyonları ve konvansiyonları için taramak, her framework için bir dışlama kuralı üretmek ve ancak sonra JavaParser AST'si üzerinden identifier toplama/yeniden adlandırma yapmak oldu. Yazarın vardığı sonuç net: Java kod obfuscation'ı bir string değiştirme problemi değil, bir framework anlama problemi.