Hediye zamanı: Eclipse için iki TCK
Oracle, Mayıs ayında Eclipse Foundation’a zaten iki TCK lisansı verdi. Sadece son birkaç gün içinde raporlar gerçekten yayıldı. İlk bakışta hediye gibi görünen şey aslında hediye değildir. Her neyse, iki lisans ünlü kovada sadece bir damla. Ama bir bir…
Teknoloji Uyumluluk Kiti
Java Topluluk Süreci (JCP) çerçevesinde, hem bir dil olarak Java hem de farklı platformlar (Java SE, Java EE, Java ME) daha da geliştirilmektedir. Bir EG’ye (uzman grubu) ek olarak, her Java Spesifikasyon İsteği (JSR) bir dizi belge ve tabii ki bir Referans Uygulama (RI) ve karşılık gelen bir TCK (Teknoloji Uyumluluk Kiti) içerir.
TCK, uygulamalara karşı çalıştırılabilir ve bunların spesifikasyona uygunluğunu doğrulayabilir. Yani, koda atılan belirtim belgesi varyantıdır. Tipik olarak uyumluluk kiti, test durumlarından ve bunları çalıştırmak için bir “test donanımından” oluşur. JCP, her JSR için bir TCK olması gerektiğini şart koşmaktadır.
Bu nedenle, ağda en az JSR sayısı kadar TCK vardır – en azından teoride vardır. Uygulamada, açık ve kullanılabilir çok fazla TCK yoktur. JBatch, CDI ve Bean Validation dışında şu an aklıma başka bir şey gelmiyor. Ancak yalnızca Java EE için en az 28 belirtim vardır. Ne yazık ki, çoğu TCK Oracle’da kilitli. Ama neden? Bunun nedeni, TCK’ların aynı zamanda bir belgelendirme aracı olarak kullanılmasıdır. Bir TCK, bir JSR uygulamasına karşı doğru ve hatasız çalışabiliyorsa, uyumlu mu diyelim?
Uyumlu platform ne anlama geliyor?
Platform uyumluluğu ile kendini mükemmel bir şekilde tanıtmaktadır. Java EE Uyumluluk Listesi, sunucu pazarının kim olduğunu gösterir. Orada söylemezsen, gerçekten fark edilme şansın yok. Burada yalnızca Apache Tomcat bilinen bir istisnadır. Peki, şimdi gerçekten sertifikaya giden yol nasıl? Java EE için Java EE Uyumluluk Test Paketi (CTS) vardır ve bu muhtemelen tüm bireysel TCK’lerin toplamından daha fazla olmayacaktır – Bunu görmedim. Erişmek için Oracle’ın lisans sahibi olmanız gerekir.
Ve burası pahalılaştığı yer. Tam olarak ne kadar pahalı bilmiyorum. Ödeme yaptıktan sonra CTS’yi Java Partner Engineering web sitesinden alabilirsiniz. Diğer tek alternatif, bireylerin veya kar amacı gütmeyen kuruluşların bir CTS’ye başvurabileceği Uyumluluk Testi Burs Programıdır. Daha sonra bir inceleme komitesi lisans verilip verilmeyeceğine karar verir. Bir PDF tam olarak nasıl çalıştığını açıklar. Apache Software Foundation’a ek olarak, diğer çeşitli kuruluşlar ve bireyler, bireysel TCK’lere ve CTS’lere erişim elde etti.
EclipseLink için TCK
Mayıs ayı başlarında yapılan bir basın açıklamasına göre Oracle, Eclipse Foundation’a iki TCK ve ilgili destek hizmetleri vererek “Java geliştiricilerine ve açık kaynak topluluğuna olan bağlılığını” gösteriyor. Bakış EclipseLink’te başlar. Bu, APP için IR değil miydi? Temelde kendi TCK’larını yapıyorlar, değil mi? Neden bir lisansa ihtiyaçları var?
O kadar basit değil: EclipseLink aslında TopLink’tir. TopLink’in geçmişine aşina olan herkes, Oracle tarafından satın alınmadan önce WebGain’e ait olan nispeten eski bir ürün olduğunu bilir. WebGain, Eclipse’in güçlü bir destekçisi oldu ve hatta 2002’de yönetim kurulunda yer aldı. Oracle’ın satın alınmasından sadece beş yıl sonra, TopLink Eclipse Vakfı’na bağışlandı ve o zamandan beri genel merkezi bu şirkette bulunuyor. EclipseLink, EPL 1.0 kapsamında lisanslanmıştır. Projenin kendisi bir TCK içermez. Bir UR için zor bir durum. Taahhüt edenlerin listesine bakarsanız, heyecan verici olur. 30 kişi ve sadece biri Oracle’dan değil. Neden bu takımın TCK’sı olduğunu ve hatta geliştirilmesine yardımcı olduğunu düşünüyorum? Açıkça söylemek gerekirse, bir Oracle lisanslama kuralını ihlal ettiler. Kanaatimce, burslu lisans burada sadece yasal bir düzenlemeydi.
Başak için TCK
Ama Başak ile her şey daha güzel değil mi? Arkasında gerçekten iyi niyet var değil mi? Belki. Virgo, SpringSource tarafından Eclipse’e bağışlanan eski Spring dm sunucusudur. Taahhüt edenlerin listesine baktığımızda, resim TopLink’ten biraz farklı. Ne yazık ki her ismin arkasında sadece SAP bulunmuyor. SAP, Pivotal ve Tasktop Technologies’den nispeten eşit bir ekip. İkincisi için, eski SpringSource COO’su Neelan Choksi artık COO’dur ve Rod Johnson danışman olarak gemide. Oracle’ın VMWare’e bir şey vermesi pek olası değil. Yani SAP buradaki itici güç olmalı. Aslında Başak zaten Java EE 6 sertifikasına sahip, ancak farklı bir isim altında. SAP NetWeaver Cloud, Java EE 6 web profili teklifini Virgo’da oluşturdu. Dolayısıyla SAP muhtemelen Oracle’dan bir lisans almıştır ve bu nedenle Virgo’yu zaten onaylamıştır. Bir maliyet tilkisi muhtemelen burada yıllık lisans ücretlerini ödememenin daha ucuz olacağına karar verdi ve Virgo projesini doğrudan Scholarshop programına kaydettirdi. Bu durumda, olumlu bir etkisi de vardır. Ticari bulut çözümü yalnızca web profili sertifikasına sahip olmakla kalmıyor, aynı zamanda çok kısa vadede muhtemelen herkes için yeni bir EE 7 sertifikalı Başak varyantı olacak. Burada, büyük bir şirketin maliyet bilinci aslında açık kaynak topluluğu için karşılığını verdi.
Ama şimdi her şey gerçekten daha mı iyi?
İki projeye iki adet daha TCK temin edildi. Geriye dönüp mevcut toplam TCK sayısına bakmak iç karartıcı. Özellikle bu durumda kurallara bağlı ödevlerle de uğraştığımız için. Atanan TCK’ler herkese açık hale getirilemez ve bu nedenle yalnızca ekipler tarafından kullanılabilir. Geçen yıl APP posta listesiyle ilgili uzun bir tartışma, bu yaklaşımla ilgili sorunları açıkça ortaya koydu. JCP, JSR-348 ile yaptığı değişikliklerle daha önce uygulanan çok katı kuralları bir nebze yumuşatsa da, TCK’ların uzun bir süre tüm ilgili taraflara açık olacağı öngörülmemektedir. Sonuç olarak, bu, özelliklerin kalitesini incitiyor. Tanımlardaki boşluklar çok geç fark edilir ve düzgün şekilde test edilmemiş UR alanları kötü hatalara yol açar. JSR 358’in bir parçası olarak, JCP kural setinin bir sonraki versiyonu üzerinde çalışılmaktadır. Eşlik eden bir Java.net projesi, tartışma belgelerini herkesin erişimine açar. Ve burada da herkes tartışmaya katılabilir ve fikrini ifade edebilir. Observer posta listesi tüm java.net kullanıcıları tarafından kullanılabilir. CloudBees, RedHat ve IBM’in kullanım hakları açısından nasıl konumlandığını öğrenmek isteyenler sunum sayfasında aradıklarını bulacaklar. Oracle, gelecekte standart TCK lisanslama modelleriyle şu şekilde ilerlemek istiyor:
“Gelecekteki tüm JSR’ler için TCK’ler, onaylanan bir veya daha fazla Açık Kaynak Lisansı ve/veya standart bir ticari TCK Lisansı kapsamında sertifikalandırma ve markalama amacıyla kullanıma sunulmalıdır. Gelecekteki tüm Şemsiye olmayan JSR’ler için TCK’lar, ilgili UR açık kaynak projesindeki tüm katılımcılara standart bir JCP Topluluk TCK lisansı altında sağlanmalıdır.“
(Kaynak: JSR 358 için Oracle önerisi, PDF, sayfa 15+16)
Doğru yönde atılmış bir adım olur ve aslında açık kaynak topluluğuna yardımcı olur. Hediye olsun ya da olmasın: İşlerin daha iyiye gitmesini istiyorsak, bir şeylerin kökten değişmesi gerekir.
()
Haberin Sonu