Scala 3.9 LTS çıktı: 3.3 kullanıcıları için ikili uyumluluk tuzağı var

Scala 3.9.0, 3 Eylül 2026’da Scala 3’ün yeni uzun süreli destek sürümü olarak yayımlandı. Scala derleyicisinin GitHub’daki 3.9.0 LTS yayın kaydı, kararlı sürümü ve öne çıkan değişiklikler arasında into mekanizmasını, Scala.js 1.22.0 ile Scala CLI 1.16.0 güncellemelerini listeliyor.

Yeni hat, Scala 3.3’ün önerilen LTS tabanı olarak yerini alıyor; ancak geçiş iki yönde aynı sonucu vermiyor. Scala 3.9 LTS duyurusu, 3.9 ile oluşturulan kitaplık artefaktlarının 3.3 projelerince tüketilemeyeceğini, 3.9 hattının en az üç yıl korunacağını ve 3.3 bakımının bir yıl daha süreceğini belirtiyor. Bu nedenle uygulama derleyicisini yükseltmek ile başkalarının kullandığı bir kitaplığı 3.9 tabanında yayımlamak farklı kararlar gerektiriyor.

Scala 3.9 LTS yenilikleri neler?

Scala 3.9, önceki LTS’den sonra dilde, derleyicide, standart kitaplıkta ve araç zincirinde biriken değişiklikleri yeni destek tabanında topluyor. En belirgin dil yeniliği, Scala 3.8’de önizleme olarak sunulan into mekanizmasının kararlı hale gelmesi. API yazarları, örtük dönüşüm kabul eden parametreleri açıkça işaretleyebiliyor; tüketicinin proje genelinde sınırsız örtük dönüşümleri etkinleştirmesi gerekmiyor.

Scala CLI tarafında JShell ile REPL kullanımı, JUnit 5 desteği ve sbt 2.x dışa aktarımı bulunuyor; Ammonite desteği ise kaldırıldı. Scala.js 1.22.0 sürümünde WebAssembly arka ucu kararlı duruma gelirken, Scala CLI içindeki WebAssembly kullanımı deneysel kalıyor. Bunlar aynı özellik için iki farklı olgunluk düzeyi: derleyici arka ucunun kararlı olması, bütün araç zincirindeki kullanım biçimlerinin kararlı olduğu anlamına gelmiyor.

Doğrudan 3.3’ten yükselen projelerin JDK 17 veya daha yenisine geçmesi gerekiyor. Kaynak kodunda da standart kitaplığın Scala 3 ile derlenmesi, bazı açık bağlam argümanlarının using biçiminde yazılmasını gerektirebiliyor. Derleyicinin sürüm geçişlerine yönelik yeniden yazma seçenekleri bu değişikliklerin bir bölümünü otomatikleştirse de, üretilen farkların incelenmesi ve tam test paketinin çalıştırılması gerekiyor.

Scala 3.3 tuzağı neden tek yönlü?

Scala 3 uyumluluk modeli, yeni derleyicinin eski Scala 3 sürümleriyle yayımlanmış kitaplıkları okuyabilmesini hedefliyor. Bu yüzden derleyicisini 3.9’a yükselten bir uygulama, genel olarak 3.3 tabanında yayımlanmış bağımlılıklarını kullanmayı sürdürebilir. Ters yönde ise 3.3 derleyicisi, 3.9 ile üretilen daha yeni TASTy biçimini okuyamaz.

Buradaki sınır yalnızca JVM’in bir sınıf dosyasını çalışma zamanında yükleyip yükleyememesiyle ilgili değil. Scala 3 derlemesi, .class dosyalarının yanında ayrıntılı tür bilgisini koruyan .tasty dosyaları üretir. Bağımlılığın API’sini derleme sırasında çözümleyen eski derleyici, kendisinden sonraki biçimdeki bu bilgiyi tüketemediğinde derleme durur.

Sonuç olarak kitaplığın yayın tabanını 3.3’ten 3.9’a çıkarmak, desteklenen en düşük Scala 3 derleyicisini de yükseltir. Kitaplığın kendi testlerinin 3.9 üzerinde geçmesi, 3.3 kullanan tüketicilerin yeni artefaktı kullanabileceğini kanıtlamaz. “LTS’den LTS’ye geçiş” etiketi bu yayın etkisini ortadan kaldırmıyor.

Scala 2.13 için TASTy Reader sınırı 3.7

Scala 2.13’teki -Ytasty-reader seçeneği, Scala 3 için yayımlanan bazı kitaplıkların Scala 2.13 projelerinden tüketilmesini sağlayan bir geçiş köprüsüydü. TASTy Reader uyumluluk açıklaması, Scala 3.7’nin bu yöntemle okunabilen son Scala 3 serisi olduğunu; 3.8 ve daha yeni artefaktların Scala 2.13 tarafından tüketilemeyeceğini ortaya koyuyor.

Bu nedenle 3.9’a geçen bir kitaplık yalnızca Scala 3.3 kullanıcılarını geride bırakmıyor. Kitaplığın Scala 3 paketini TASTy Reader üzerinden kullanan Scala 2.13 projeleri de yeni yayını alamıyor. Ters yön korunuyor: Scala 3 projeleri, Scala 2.13 için yayımlanmış artefaktları tüketmeye devam edebiliyor.

Her iki seriyi destekleyen kitaplıklar için doğrudan çözüm, Scala 2.13 ve Scala 3 paketlerini kendi derleyicileriyle ayrı ayrı üretmek. Çapraz yayımlama yapılmıyorsa 3.3 tabanlı Scala 3 artefaktını geçiş döneminde korumak daha geniş bir tüketici kümesine ulaşır; bunun karşılığında yayımlanan API, 3.3 sonrasında gelen dil ve standart kitaplık özelliklerine dayanamaz.

Uygulama, yayıncı ve tüketici için karar matrisi

Yükseltme kararı projenin ekosistemdeki rolüne göre ayrılıyor:

• Uygulama ekibi: JDK ve derleme araçlarını uyumlu hale getirdikten sonra derleyiciyi 3.9’a taşıyabilir. Daha yeni derleyicinin eski Scala 3 kitaplıklarını tüketebilmesi, bağımlılık güncellemelerinin derleyici geçişinden sonra ele alınmasına imkân verir.
• Scala 3 kitaplığı yayıncısı: Yalnızca 3.9 ile yeni artefakt yayımlamak, 3.3 tüketicilerinin o sürüme erişimini keser. Yayın tabanı değişikliği bu yüzden sıradan bir yama güncellemesi değil, desteklenen en düşük derleyiciye ilişkin politika kararıdır.
• Scala 2.13 tüketicisi: TASTy Reader üzerinden 3.9 artefaktını kullanamaz. Bağımlılığın Scala 2.13 için çapraz yayımlanmış paketine veya en fazla Scala 3.7 ile üretilmiş uyumlu bir sürümüne ihtiyaç duyar.

Scala 3.3 hemen kullanım dışı kalmış değil; açıklanan ek bakım yılı, yayıncılara tüketici tabanını ölçmek ve geçiş politikasını duyurmak için süre bırakıyor. Mevcut durumda uygulamalar için 3.9’a yükseltme yolu açık, fakat kitaplık yayıncılarının belirleyici sorusu yeni özelliklerden önce desteklemek zorunda oldukları en eski Scala 3 ve Scala 2.13 tüketicileri.

Ayrıca okuyun:

• 128 kuruluş aynı uyarıda birleşti: Kritik altyapının yalnızca ayları var
• Thunderbird 155 çıktı: Yüksek riskli bellek hataları da yamalandı
• Claude güvenlik araştırmacılarını geçti, ama ölçümün bir sınırı var