Önceki bir gönderide, Java Platform Modül Sistemi (JPMS) için minimum destek ve buna nasıl ulaşılacağı hakkında yazmıştım. Ancak, kitaplıkların Java modül sistemini desteklemediği tekrar tekrar olabilir ve bunların gelecekte en azından “otomatik modüller” olarak mevcut olması beklenmemelidir.
Hendrik Ebbers (@hendrikEbbers), JCP Uzman Grubunun bir üyesi olan Java Şampiyonu ve birçok kez JavaOne’ın Rockstar Konuşmacısı olarak ödüllendirildi. Hendrik, Open Elements şirketi aracılığıyla şu anda Hedera Hashgraph’ın tasarlanmasına ve hizmetlerinin halka sunulmasına yardımcı oluyor. Hendrik, JUG Dortmund ve Cyberland’in kurucu ortağıdır ve dünya çapında Java üzerine dersler ve atölye çalışmaları yapmaktadır. “Mastering JavaFX 8 Controls” adlı kitabı Oracle Press tarafından 2014 yılında yayınlandı. Hendrik, JakartaEE veya Eclipse Adoptium gibi açık kaynaklı projelerde aktif olarak yer alıyor. Hendrik, AdoptOpenJDK TSC ve Eclipse Adoptium WG’nin bir üyesidir.
Kodunuzu JPMS’ye dönüştürmek istiyorsanız ve bu kitaplıklara bağlıysanız, bazen numara çantanıza girmeniz gerekir. Bu yazıda, tam olarak bu bağımlılıkları incelemek ve onlarla nasıl başa çıkabileceğinizi görmek istiyorum.
Geçici çözüm olarak Gradle eklentisi
Maven ile daha rahat olsam da, yakın zamanda büyük bir Gradle projesini Java modüllerine geçirmek için çalıştım. Proje açık kaynak kodlu olduğu için GitHub üzerinden rahatlıkla görüntülenebilir. Bu projede, port başlangıcında, Java modül sistemini desteklemeyen çok sayıda bağımlılık vardı. Bazıları için, ilgili projeler için doğrudan çekme istekleri (PR) oluşturarak sürdürülebilir bir çözüme ulaşmayı başardık. Automatic-Module-Name tamamlamak. Konuyla ilgili önceki yazıda bunun bir Maven veya Gradle eklentisi kullanılarak nasıl kolayca elde edilebileceğini zaten açıkladım. Böyle bir PR örneği burada bulunabilir.
Ancak, böyle bir PR’nin basitçe sağlanamadığı veya PR’nin kabul edilmediği bağımlılıklar da vardır. Belki de daha fazla gelişmesi durdurulmuş bir bağımlılığınız bile var. Tüm bu durumlarda, farklı bir uygulama gereklidir. Temel olarak, Java modüllerini bağımlılıklardan kendiniz oluşturmaya özen göstermelisiniz. Bunu yapmanın birkaç yolu var. Örneğin, manuel olarak girebilirsiniz. Automatic-Module-Name-Jar bildirimine bir giriş ekleyin ve ardından değiştirilmiş sürümü dahili bir maven deposunda barındırın. Bahsi geçen Gradle projesi için Jendrik Johannes’in “extra-java-module-info” eklentisini kullandık. Açık kaynak olarak mevcut olan bu eklenti, derleme zamanında bir Automatic-Module-Name Bağımlılık girişi ekleyin. Spesifik olarak, eklenti aşağıdaki örnekte olduğu gibi her biri ile birlikte kullanılır. automaticModule(…) birinci parametre olarak bağımlılığın Gradle tanımlayıcısını ve ikinci parametre olarak kullanılacak modülün adını çağırır:
plugins {
id("org.gradlex.extra-java-module-info")
}
extraJavaModuleInfo {
failOnMissingModuleInfo.set(true)
automaticModule("io.prometheus:simpleclient",
"io.prometheus.simpleclient")
automaticModule("io.prometheus:simpleclient_common",
"io.prometheus.simpleclient_common")
automaticModule("io.prometheus:simpleclient_httpserver",
"io.prometheus.simpleclient.httpserver")
}
Eklenti yazarıyla birlikte, her şeyi önemli ölçüde çok verimli bir alışverişe dönüştürebildik. Otomatik formlara ek olarak, eklenti her zaman uzantılı formlar oluşturabilmiştir. module-info.java yaratmak. Ancak ihracat gibi bilgilerin manuel olarak tanımlanması gerekiyordu. Yeni özellikler sayesinde artık bir modülü, tüm paketleri dışa aktarılacak şekilde tanımlamak mümkün (daha fazla bilgiye bakın). Bu, otomatik modüllerle çalışmak zorunda kalmamanız gibi büyük bir avantaja sahiptir, bu da bazı tuhaflıklara yol açar, çünkü diğer şeylerin yanı sıra, tüm otomatik modüller, bir otomatik modül “olarak işaretlenir işaretlenmez bir modülün “gerekli” bağımlılıklarına eklenir. gerekli” ” dosyada module-info.java belirtildi (bkz. Java Spesifikasyonu). Kütüphane sorumlusu olarak Jendrik Johannes’e tekrar çok teşekkürler. Benim görüşüme göre, işbirliğimiz açık kaynağın faydalarını çok iyi gösterdi. Bu konuya dalmak isteyen herkes için Jendrik, YouTube’da bu ve Gradle ile ilgili diğer konularda ücretsiz olarak birkaç video barındırdı.
Bir sorun kaldı
Bununla birlikte, burada sunulan uygulamalarla son bir büyük sorun çözülemez: Bir JAR, Java modülü sistem paketi bölme kısıtlamalarını ihlal eder etmez, modül yoluna eklenemez. Bu durumda, hala geniş kapsamlı adımların atılması gerekiyor. Ama bu noktaya bir sonraki yazımda değineceğim.
(rm)
Haberin Sonu
Hendrik Ebbers (@hendrikEbbers), JCP Uzman Grubunun bir üyesi olan Java Şampiyonu ve birçok kez JavaOne’ın Rockstar Konuşmacısı olarak ödüllendirildi. Hendrik, Open Elements şirketi aracılığıyla şu anda Hedera Hashgraph’ın tasarlanmasına ve hizmetlerinin halka sunulmasına yardımcı oluyor. Hendrik, JUG Dortmund ve Cyberland’in kurucu ortağıdır ve dünya çapında Java üzerine dersler ve atölye çalışmaları yapmaktadır. “Mastering JavaFX 8 Controls” adlı kitabı Oracle Press tarafından 2014 yılında yayınlandı. Hendrik, JakartaEE veya Eclipse Adoptium gibi açık kaynaklı projelerde aktif olarak yer alıyor. Hendrik, AdoptOpenJDK TSC ve Eclipse Adoptium WG’nin bir üyesidir.
Kodunuzu JPMS’ye dönüştürmek istiyorsanız ve bu kitaplıklara bağlıysanız, bazen numara çantanıza girmeniz gerekir. Bu yazıda, tam olarak bu bağımlılıkları incelemek ve onlarla nasıl başa çıkabileceğinizi görmek istiyorum.
Geçici çözüm olarak Gradle eklentisi
Maven ile daha rahat olsam da, yakın zamanda büyük bir Gradle projesini Java modüllerine geçirmek için çalıştım. Proje açık kaynak kodlu olduğu için GitHub üzerinden rahatlıkla görüntülenebilir. Bu projede, port başlangıcında, Java modül sistemini desteklemeyen çok sayıda bağımlılık vardı. Bazıları için, ilgili projeler için doğrudan çekme istekleri (PR) oluşturarak sürdürülebilir bir çözüme ulaşmayı başardık. Automatic-Module-Name tamamlamak. Konuyla ilgili önceki yazıda bunun bir Maven veya Gradle eklentisi kullanılarak nasıl kolayca elde edilebileceğini zaten açıkladım. Böyle bir PR örneği burada bulunabilir.
Ancak, böyle bir PR’nin basitçe sağlanamadığı veya PR’nin kabul edilmediği bağımlılıklar da vardır. Belki de daha fazla gelişmesi durdurulmuş bir bağımlılığınız bile var. Tüm bu durumlarda, farklı bir uygulama gereklidir. Temel olarak, Java modüllerini bağımlılıklardan kendiniz oluşturmaya özen göstermelisiniz. Bunu yapmanın birkaç yolu var. Örneğin, manuel olarak girebilirsiniz. Automatic-Module-Name-Jar bildirimine bir giriş ekleyin ve ardından değiştirilmiş sürümü dahili bir maven deposunda barındırın. Bahsi geçen Gradle projesi için Jendrik Johannes’in “extra-java-module-info” eklentisini kullandık. Açık kaynak olarak mevcut olan bu eklenti, derleme zamanında bir Automatic-Module-Name Bağımlılık girişi ekleyin. Spesifik olarak, eklenti aşağıdaki örnekte olduğu gibi her biri ile birlikte kullanılır. automaticModule(…) birinci parametre olarak bağımlılığın Gradle tanımlayıcısını ve ikinci parametre olarak kullanılacak modülün adını çağırır:
plugins {
id("org.gradlex.extra-java-module-info")
}
extraJavaModuleInfo {
failOnMissingModuleInfo.set(true)
automaticModule("io.prometheus:simpleclient",
"io.prometheus.simpleclient")
automaticModule("io.prometheus:simpleclient_common",
"io.prometheus.simpleclient_common")
automaticModule("io.prometheus:simpleclient_httpserver",
"io.prometheus.simpleclient.httpserver")
}
Eklenti yazarıyla birlikte, her şeyi önemli ölçüde çok verimli bir alışverişe dönüştürebildik. Otomatik formlara ek olarak, eklenti her zaman uzantılı formlar oluşturabilmiştir. module-info.java yaratmak. Ancak ihracat gibi bilgilerin manuel olarak tanımlanması gerekiyordu. Yeni özellikler sayesinde artık bir modülü, tüm paketleri dışa aktarılacak şekilde tanımlamak mümkün (daha fazla bilgiye bakın). Bu, otomatik modüllerle çalışmak zorunda kalmamanız gibi büyük bir avantaja sahiptir, bu da bazı tuhaflıklara yol açar, çünkü diğer şeylerin yanı sıra, tüm otomatik modüller, bir otomatik modül “olarak işaretlenir işaretlenmez bir modülün “gerekli” bağımlılıklarına eklenir. gerekli” ” dosyada module-info.java belirtildi (bkz. Java Spesifikasyonu). Kütüphane sorumlusu olarak Jendrik Johannes’e tekrar çok teşekkürler. Benim görüşüme göre, işbirliğimiz açık kaynağın faydalarını çok iyi gösterdi. Bu konuya dalmak isteyen herkes için Jendrik, YouTube’da bu ve Gradle ile ilgili diğer konularda ücretsiz olarak birkaç video barındırdı.
Bir sorun kaldı
Bununla birlikte, burada sunulan uygulamalarla son bir büyük sorun çözülemez: Bir JAR, Java modülü sistem paketi bölme kısıtlamalarını ihlal eder etmez, modül yoluna eklenemez. Bu durumda, hala geniş kapsamlı adımların atılması gerekiyor. Ama bu noktaya bir sonraki yazımda değineceğim.
(rm)
Haberin Sonu