Neden paketler ve modüller Java 9'da ayrı kavramlardır?

Java 9, paketlere ek olarak modüllere de sahip olacak. Genellikle dillerin biri ya da diğeri vardır. Ve çoğu programcı iki terimi eş anlamlı olarak algılar . Modüller, ilkel olarak muamele ederek paketlerin üzerine inşa edilir. Kompozit desen, ilkel ve kompozitlerin eşit şekilde işlenmesini önerir. Aksi takdirde kötü şeyler olur. Örneğin, ilkel (değer) ve referans türleri için ortak süpertipi güçlendirmeye çalıştıkları Valhalla projesine bakın.

Modüller ve paketler anlamsal olarak ayrı kavramları mı temsil ediyor? Bunu Anlamı hem sahip olmak mantıklı herhangi bir dilde (endişeleri ayrılması). Yoksa Java, geriye dönük uyumluluğa bir övgü olarak mı sahip olmalıdır?

Mevcut konsepti güçlendirmek yerine neden yeni bir konsept sunalım?

JSR 376 : "Java platform modülü sistemi" proje Jigsaw içinde uygulandı .

SOTMS'a göre

Bir modül, kod ve verilerin adlandırılmış, kendi kendini tanımlayan bir koleksiyonudur. Kodu, Java sınıfları ve arabirimleri gibi türleri içeren bir paket kümesi olarak düzenlenmiştir; verileri kaynakları ve diğer statik bilgileri içerir.

JLS, paketin ne olduğunu tanımlamaktan dikkatle kaçınır . Gönderen Vikipedi :

Java paketi, Java sınıflarını Modula modüllerine benzer ad alanlarına yerleştirerek, Java'da modüler programlama sağlayan bir tekniktir.

Wikipedia'dan alıntı yapmanın kötü bir uygulama olduğunu biliyorum, ancak ortak anlayışı yansıtıyor. Gönderen girişi modüler programlama:

Vadeli paket bazen yerine kullanılan modül (Dart, Go veya Java gibi). Diğer uygulamalarda, bu farklı bir kavramdır; Python'da bir paket bir modül koleksiyonudur, yaklaşan Java 9'da ise yeni modül konseptinin (gelişmiş erişim kontrolü olan bir paket koleksiyonu) sunulması planlanmaktadır.

Kavram bir modülün bu kavramın örnekleme farklıdır.

Java'nın her zaman modülleri vardır. Bir yöntem bir modül, bir sınıf ve bir paket. Bir modül, iç detayların gizlendiği ve üzerinde anlaşmaya varılan sözleşmeler yoluyla diğer modüllerle iletişim kuran bir kuruluş birimidir. Örneğin, bir yöntem, gizli dahili (kod ve yerel değişkenler) ve bir sözleşmeye (parametreler ve dönüş türü) sahip olduğu için bir modüldür. Modüller daha düşük seviyeli modüllerden oluşabilir, örneğin sınıflar yöntemler içerir.

Çekirdek Java'da (9 öncesi) eksik olan konuşlandırılabilir bir modüldür. Yukarıdaki tüm modül türleri kopyalanabilecek konuşlandırılabilir birimler değildir. Java'nın JAR dosyası adı verilen konuşlandırılabilir bir yapısı vardır, ancak bunlar kapsül veya sözleşme içermedikleri için modüller değildir: çalışma zamanında JAR dosyaları kaybolur ve hepsi tek bir "sınıfyolunda" birleşir.

OSGi , 1998'de konuşlandırılabilir modüllerin eksikliğini "paket" kavramı ile ele aldı. Bunlar fiziksel olarak JAR dosyalarıdır ve paketler içerir, ancak OSGi, bu düzeyde kapsüllemeyi ve sözleşmeleri desteklemek için bir çalışma zamanı sistemi ile birlikte ek meta verileri tanımlar.

Java 9, OSGi'ye benzer şekilde konuşlandırılabilir modüllerin eksikliğini giderir. Tartışmasız bu tamamen gereksizdi çünkü OSGi var ve çalışıyor, ama bu tamamen farklı bir tartışma ...

Ne yazık ki Java 9, yeni modül konseptini sadece "modül" olarak adlandırarak suları çamurluyor. Bu, yöntemlerin, sınıfların ve paketlerin modül olmayı bıraktığı anlamına gelmez! Bir J9 "modülü", modül konseptinin bir başka örneğidir . OSGi paketleri gibi, J9 modülleri de paketlerden oluşur ve bunlar kopyalanabilen fiziksel yapay öğelerdir (genellikle JAR dosyaları). Çalışma zamanı sistemi bunları anlar ve kabul eder.

Özet: evet J9 modülleri ve paketleri anlamsal olarak ayrı kavramlardır. Açıkçası Java, geriye dönük uyumluluk için mevcut paket konseptini korumalıdır. "Paket" kelimesinin Java'da diğer dillerde veya RPM gibi paket yönetim sistemlerinde oldukça farklı kullanıldığını unutmayın. Yeni J9 modülleri (ve OSGi paketleri), RPM'deki Java paketlerinden çok daha fazla pakete benziyor.

Bir cevapta tehlike vermeme izin verin, ancak çoğu varsayım / bölme kılları / sıralaması vb.

Aynı şey mi? Eh evet ^_ve hayır

Gönderen "Java 9'da Modülerlik" ile ilgili bu JavaWorld makalesinde :

Modüler bir çözüm olarak paketler

Paketler, Java programlama ortamına bir miktar soyutlama eklemeye çalışır. Benzersiz kodlama ad alanları ve yapılandırma bağlamları için olanaklar sağlarlar. Ne yazık ki, paket kuralları kolayca atlatılabilir ve sıklıkla tehlikeli derleme zamanı kaplinleri ortamına yol açar.

As @ user2418306 (OP) ima etti, " modülleri paketleri doğru yapılır " . Java'daki modüller ve paketler (açıkça Java 9'dan itibaren) (OP'nin istediği gibi) anlamsal olarak aynı şeydir. Yani, önceden derlenmiş JVM bayt kodunun koleksiyonlarıdır, diğer meta verilerle - esas olarak kütüphanelerdir .

Peki fark nedir?

Ancak, fark her birinin içindeki meta verilerdedir . Java packagebildirimleri veya JAR bildirimleri, genellikle kitaplık geliştiricileri tarafından korunmaz ve JAR / paketinin sağladığı şey hakkında kesin bir sözleşme sağlamaz. Burada açıklandığı gibi (yine JavaWorld makalesi) :

JAR dosyaları yeterince modüler değil mi?

JAR dosyaları ve çalıştıkları dağıtım ortamı, başka türlü mevcut olan birçok eski dağıtım kuralında büyük ölçüde iyileşir. Ancak JAR dosyalarının, nadiren kullanılan bir .jar bildiriminde gizlenmiş sürüm numarası dışında, özgün bir benzersizliği yoktur. JAR dosyası ve isteğe bağlı bildirim, Java çalışma zamanı ortamında modülerlik kuralları olarak kullanılmaz. Bu nedenle, dosyadaki sınıfların paket adları ve bir sınıf yoluna katılımları, JAR yapısının çalışma zamanı ortamına modülerlik kazandıran tek parçalarıdır.

Diğer diller / ortamlar, vb. Hakkında bir rant

Bu makalede ele alınan bir başka alan da Maven gibi derleme sürecinin bir parçası olarak sizin için bağımlılıkları yöneten sistemlerdir . Gönderen Apache Maven sitede bu sayfada :

Bağımlılık yönetimi:

Maven, JAR'ların ve diğer bağımlılıkların merkezi bir havuzunun kullanılmasını teşvik eder. Maven, projenizin müşterilerinin, projenizi oluşturmak için gereken herhangi bir JAR'ı Perl'in CPAN'ı gibi merkezi bir JAR deposundan indirmek için kullanabileceği bir mekanizma ile birlikte gelir. Bu, Maven kullanıcılarının JAR'ları projeler arasında yeniden kullanmalarını sağlar ve geriye dönük uyumluluk sorunlarının ele alınmasını sağlamak için projeler arasındaki iletişimi teşvik eder.

Şimdi sanki oradaymışım gibi gelecek hakkında konuşmak için

Gibi o sayfa belirtildiği, (Perl gibi) diğer diller (gibi paket depoları var CPAN ). Bu, son on yılda (empati kanıtı olmadan öyle hissediyorum, çünkü öyle hissediyorum). Ruby'nin mücevherleri , Python'un PyPi'si ve Düğüm paketi yöneticisi ( npm) gibi araçlar , doğru öğeleri (paketler, modüller, taşlar, gizmo, vb.). Bir fikir (Hissettiğim) oldu " ödünç " Böyle Debian'ın olarak Linux® dağıtım sistemlerinden apt , RedHat yıllarınrpm(Her ne kadar belli ki, en az bir nesil evrimleşti ve bunları daha güzel hale getirdi.)

Java modülleri , zaten yapamayacağınız hiçbir şey eklememelerine rağmen, bağımlılıklar / paket yönetimi ve otomatik derleme ortamları için araçları çok daha kolay hale getirir . Bunun modülleri daha iyi hale getirip getirmediğini söylemeyi reddediyorum. : P