Bir kez yazın, her yerde koşun – gerçekten uyumlu java ne kadar?
“Bir kez yaz, her yerde koş” (WORA), Sun Microsystems 1995 Java platformunu tanıttı. Bu slogan, JVM'nin iki farklı avantajını birleştirdi: JVM (Java sanal makine) kullanılarak, derlenmiş programlar bir JVM'nin kullanılabilir olduğu tüm platformlarda gerçekleştirilebilir. Örneğin, Windows'ta derlenen bir Java uygulaması Linux'ta bir JVM'de kolayca gerçekleştirilebilir.
Hendrik Advers (@hendrikebbers), JCP uzman grubunun bir üyesi olan Java'nın şampiyonu ve farklı Javaone rock yıldızı hoparlörleri aldı. Kendi açık unsurları şirketi ile Hendrik şu anda Hedera Hashgraph'ı tasarlamaya ve hizmetlerini halka açık hale getirmeye yardımcı oluyor. Hendrik aynı zamanda Juug Dortmund ve Cyberland tarafından ve tüm dünyada Java teması hakkında dersler ve seminerler düzenliyor. “Mastering JavaFx 8 Controls” adlı kitabı 2014 yılında Oracle Press tarafından yayınlandı. Hendrik, TSC Emptopenjdk ve Eclipse WG benimseyenlerin bir üyesidir.
Sloganın ikinci yönü Java'nın daha düşük uyumluluğudur. Bir Java sürümü ile tamamlanan yazılım, gelecekteki Java sürümlerinde de kolayca yapılmalıdır. Ancak son yıllarda, bu vaatte çok şey değişti.
JCL'de özel arılar tarafından dibe doğru uyumluluk
Düşen uyumluluk, Java sınıfı Kütüphanesi'ndeki (JCL) kamu ve özel arıları ayırarak Java'da daima mümkün olmalıdır. JCL, her gün çalıştığımız Java-api'nin tüm sınıflarını içerir, örneğin java.lang.String VEYA java.util.List. Ama aynı zamanda daha egzotik dersler sun.misc.Unsafe Onlar JCL'nin bir parçası. Java Virtual Machine (JVM) ve Java (JAVAC) derleyicisi gibi çeşitli araçlarla birlikte JCL, Javase'in geliştiricilerin her gün çalıştığı JDK'yı tanımlar.
JCL'nin özel API'si sınıf yolunda bulunur, ancak asla doğrudan uygulamalar tarafından kullanılmamalıdır. OpenJDK'daki dahili değişiklikler genellikle bu sektörde uygulanır ve bu da özel API arayüzlerinde olası değişiklikleri içerebilir. Genel olarak, JCL'nin tüm sınıflarının, paketlerinin java.* VEYA javax.* Başlayın, özel AAPI'ye aitler, bazı Java dağılımları JavaFx içerdiğinden, yine de yapabilirsiniz javafx.* eklemek.
Derleme süresi veya terim sırasında özel API sınıflarını kullanan yazılım artık Java'dan her (daha büyük) sürüm için koşma riski altında değildi. Kullanım doğrudan derleme döneminde bulunabilirken, bazıları yürütme aşamasında kullanım sırasında, örneğin yansıma veya geçiş bağımlılıkları yoluyla kullanım açısından bile meydana gelmiştir.
Java 9 ve modül sisteminin tanıtımı ile her şey değişti. Modül sistemi, API'nın arıları dış dünyadan gizlemesine ve bu nedenle sadece modülünüzde kullanılabilir hale getirmesine izin verir. Sonuç olarak, Java'nın özel arıları tamamen gizli olabilir.
Bu özel arılar birçok program ve kütüphane tarafından kullanıldığından, Java 9 ile bu kesim kesinlikle muazzam dönüşümlere yol açacaktır. Bu nedenle, OpenJDK'da Java 9'dan Java 15'e kadar özel arıların kullanılmaya devam edebileceğine karar verildi. Yazılım özel arılara erişirse yalnızca bir uyarı verilir. Bunun için parametre illegal-access Varsayılan olarak Java 9 ila 15'te bulunan tanıtıldı warn Ayarlanmış. Parametre, komut satırının bir parametresi olarak JVM'nin başında değiştirilebilir.
Böylece bu sürümlerde de ekleyebilirsiniz. --illegal-access=deny Zaten bir Java programının artık JCL'nin özel arılarını kullanamayacağından emin olun. Bu aynı zamanda JDK 16'nın standart davranışıydı. Burada bayrağı aktif olarak açmalısınız warn Uygulamanızın özel arıları kullanmasını sağlamak istiyorsanız. Ancak Java 17 LTS'nin piyasaya sürülmesiyle, bu seçenek tamamen kaldırıldı. Değerler permit,, warn VE debug Onlar bunun içindeydiler illegal-access Bayrak kaldırıldı, yani özel arılara genel erişime izin vermenin artık mümkün olmadığı anlamına geliyor. Hala Java 17 ile özel arılar kullanmak zorunda kalırsanız, yine de bunu yapabilirsiniz --add-opens-Flag veya Add-Opens-Belirli modülleri etkinleştirmek için manifestoda.
Araçlar veya JVM'deki değişiklikler
Araçların veya JVM'nin varyasyonları Java'nın uyumluluğunu da etkileyebilir. Örneğin Java 10 ile JEP 286, kullanımı için Java diliydi. var genişletildi. Sonuç olarak, derleyici tarafından belirlenebiliyorsa, Java'daki değişken türü artık manuel olarak uygulanmamalıdır. İşte bir örnek:
var list = new ArrayList<String>(); // infers ArrayList<String>
var stream = list.stream(); // infers Stream<String>
Tanıtımı var Java dilinde bazı etkiler oldu. Olsa bile var Java sözdizimine anahtar kelime olarak eklenmedi, yani hala mümkün olduğu anlamına gelir, var değişken ad olarak kullanılacak. Durumu var Java dilinde “ayrılmış tip adı” olarak tanımlanır (bkz. JEP 286). Ancak, bu artık dersler veya arayüzler yapmak mümkün değil var Bahsetmek için. Bu sadece çok az Java programında olmuş olsa da, Java ile uyumluluk içinde bir kırılma.
Uyumluluğu aşağıya doğru korumak için arıları amortisman
Java'nın ilk versiyonu 1996'da yayınlandı. Java sadece bir programlama dili olarak gelişmediği için değil, aynı zamanda programlama paradigmalarının da birçok arısı Java olarak değiştirildi. 1996'da hala tipik olan modeller bu günlerde kısmen modası geçmiş. Buna ek olarak, OpenJDK geliştiricileri zaman zaman hatalar yapar ve bu nedenle bugünün bilgisine göre artık kullanılmaması gereken arılar yaratırlar.
Bununla birlikte, Java'yı aşağı doğru uyumlu tutmak için, bu arılar kamu arıları JCL'nin bir parçası ise çıkarılmamıştır. Burada Javadoc'ta kullanım başlangıçta uyarıldı ve alternatif arılar genellikle doğrudan önerildi. Ek açıklamayı Java 1.5 ile tanıtarak, bu yapabildi @Deprecated-Notasyon tekrar geliştirilebilir. Bu ek açıklama, kullanıcıya yalnızca bir API'nın artık kullanılmaması gerektiğini değil, aynı zamanda Java derleyicisinin bir uyarı (hatta yapılandırmaya bağlı olarak bir hata) oluşturduğunu gösteriyor. IDE'lerde bile, program kodunun (eski) kullanımdan kaldırılmış olarak işaretlenmiş arılara erişip erişmediğini hızlı bir şekilde görebilmemiz için bugün her şey açıkça vurgulanır.
Prosedür uzun süredir çalışmış olsa da, openJDK'da giderek daha fazla kod ortaya çıktı @Deprecated Not edildi ve bu nedenle her versiyon ve değişim ile korunması gerekiyordu. Java-Fi de gittikçe şişti. Java modülleri sisteminin hareketi ve JCL'nin ayrı modüllere bölünmesi ile tamamen farklı sorunlar ortaya çıktı: asla kaldırılmayan birçok eski kod noktası, OpenJDK'da kolayca çözülemeyen tamamen vahşi bağımlılıklardı.
Bu nedenle, Java 9 ile @Deprecated-özniteliğin etrafında artarma forRemoval genişletildi. Bu özellik, bir API, @Deprecated(forRemoval=true) Java'nın gelecekteki bir versiyonunda kaldırılabilir. Java'nın yeni sürüm treni ve her altı ayda bir yeni sürümler nedeniyle, bazen son derece hızlı olabilir. Ve Java'nın en son sürümleri de bunun kullanıldığını gösteriyor. Diğer şeylerin yanı sıra, Corba-Fi, çeşitli arayüzler aşağıdaydı java.security.acl.* Veya yöntemler java.lang.SecurityManager Kaldırıldı. . java.lang.SecurityManager Ayrıca JCL'den tamamen çıkarılmalıdır.
Değişiklik satın alım
Değişiklikleri farklı bir şekilde kontrol etmek ve değerlendirmek için iki Java sürümü arasındaki değişiklikler, bir süredir Javaalmanac web sitesi vardı. Burada Java sınıfı kütüphanesindeki tüm farklılıklar iki Java sürümü arasında görüntülenebilir. Yalnızca uzun vadeli desteğe (LTS) sahip sürümler değil, Java 1.0'ın tüm ana sürümleri değil, bir değişiklikten önce veya Java'nın yeni bir LTS sürümünün ortaya çıkmasından önce yazılımınızı değiştirmeye başlayabilirsiniz. Değişikliklere ek olarak, araç ayrıca tüm sınıfları, işlevleri ve diğer öğeleri de gösterir. @Deprecated not edildi.
Ve bu geliştiriciler için ne anlama geliyor?
Java, programlama dillerinin daha fazla yenilikçi ve çevik gelişme ile sürekli uyumluluk arasında karar vermesi gerektiğini göstermiştir. En eski dil olur, daha kontamine siteler beraberinde getirir. API'nın birçok kısmı artık güncellenmiyor ve modern paradigmalara uyum sağlamak zor. Bu nedenle, bir dilin bazen kontamine alanları denize başlatması mantıklıdır. Tabii ki, kullanıcıları unutmamalısınız ve bu konuları hassas olana duyarlı hale getirmeniz gerekir.
Benim düşünceme göre, Java yöneticileri bu dengeleme eylemini uzun bir süre amortisman arılarının kaldırılması gibi yeni kavramları açıklayarak iyi yönettiler. Ayrıca toplumdan gelen eleştiriler ve geri bildirimlerle karşı karşıya kaldılar. Kesinlikle sınıf yönetimi burada geçerlidir sun.misc.Unsafe İyi bir örnek olarak. OpenJDK'dan çıkarılması uzun zamandır tartışılmıştır. Çerçeve ve kütüphaneler geliştiricileri için, uyumluluğu aşağıya doğru garanti etmek için OpenJDK'ya başka işlevler de eklenmiştir. Kavanozlu çoklu salınan kavanoz (JEP 238) ile kavanozlar farklı Java sürümleri için belirli sınıflar içerebilir ve bu nedenle uyumluluğu önemli ölçüde artırabilir.
Ancak, bu değişiklikler Java sürümleri arasındaki değişiklik ile uzun zamandır bekleyen geliştiricilere geliyor. Ancak, her zaman Java'nın mevcut LTS sürümüne geçer ve burada açıklanan kavramları ve araçları biliyorsanız, çalışma genellikle yönetilebilir.
(RME)