Mengapa paket dan modul merupakan konsep terpisah di Java 9?

21

Java 9 akan memiliki modul selain paket. Biasanya bahasa memiliki satu atau yang lain. Dan sebagian besar programmer menganggap dua istilah sebagai sinonim. Modul dibangun di atas paket, memperlakukannya sebagai primitif. Pola komposit menyarankan untuk memperlakukan primitif dan komposit secara seragam. Kalau tidak, hal-hal buruk akan terjadi. Misalnya, lihat proyek Valhalla, di mana mereka mencoba untuk menyesuaikan jenis umum untuk tipe primitif (nilai) dan referensi.

Apakah modul dan paket mewakili gagasan yang terpisah secara semantik? Berarti masuk akal memiliki keduanya untuk bahasa apa pun (pemisahan kekhawatiran). Atau Java harus memiliki keduanya sebagai penghargaan untuk kompatibilitas?

Mengapa memperkenalkan konsep baru alih-alih menambah yang sudah ada?

JSR 376 : "sistem modul platform Java" diimplementasikan dalam Jigsaw proyek .

Menurut SOTMS

Modul adalah kumpulan kode dan data yang diberi nama dan menggambarkan dirinya sendiri. Kodenya diatur sebagai seperangkat paket yang berisi tipe, yaitu kelas dan antarmuka Java; datanya mencakup sumber daya dan jenis informasi statis lainnya.

JLS dengan hati-hati menghindari mendefinisikan apa itu paket . Dari Wikipedia :

Paket Java adalah teknik untuk mengatur kelas Java ke dalam ruang nama yang mirip dengan modul Modula, menyediakan pemrograman modular di Jawa.

Saya tahu bahwa mengutip Wikipedia adalah praktik yang buruk, tetapi mencerminkan pemahaman bersama. Dari entri pada pemrograman modular:

Paket istilah kadang-kadang digunakan sebagai ganti modul (seperti di Dart, Go, atau Java). Dalam implementasi lain, ini adalah konsep yang berbeda; dalam Python paket adalah kumpulan modul, sementara di Java 9 yang akan datang diperkenalkan konsep modul baru (kumpulan paket dengan kontrol akses yang ditingkatkan) direncanakan.

java language-design modules packages pengguna2418306
sumber
3
Saya pikir Anda mengajukan banyak pertanyaan bersama di sini? 1) Apakah modul dan paket ide semantik yang sama? 2) (jika tidak 1), apakah jigsawmodul-gaya hanya peningkatan teknis atas paket? 3) (jika bukan 1 dan jika 2), Java sederhana (atau tampaknya) menjaga kedua konsep untuk kompatibilitas mundur. Beberapa dari pertanyaan ini dapat dijawab, beberapa di antaranya berorientasi pada pendapat. Saya pikir suntingan yang menyederhanakan klarifikasi yang dicari ada di sini.
Tersosauros
1
@Tersosauros Anda telah mengklasifikasikan pertanyaan "sebagian" sebagai di luar topik, tetapi tidak memberi label pertanyaan mana yang mana. Saya melihatnya hanya sebagai satu pertanyaan (1). Lainnya akan diselesaikan secara otomatis. Kompatibilitas mundur untuk java bukan pertanyaan. Jadi, baik modul yang diperkenalkan java untuk menambal kekurangan desain paket atau dua gagasan benar-benar terpisah. Dan kebingungan adalah karena penamaan yang buruk.
user2418306
1
Saya ingin memperjelas pertanyaan. Tetapi saya perlu memahami bagian mana yang menurut Anda tidak bisa dijawab. Ketika saya pikir hanya ada satu bagian.
user2418306
Ahh, aku mengerti kebingungannya. Saya pikir pertanyaan # 1 dapat dijawab (jawaban itu adalah "Ya, tapi tidak" - di situlah # 3 masuk). Saya setuju tentang # 3, jelas Java tidak akan mengubah apa kata kunci bahasa suka package/ tidak / berarti, juga tidak akan berubah menjadi (mari kita hadapi itu, cukup mengerikan) sistem classpath di JRE. Pertanyaan # 2 Saya merasa terutama berorientasi pada pendapat (itu bisa dijawab , tetapi jawaban saya dan orang lain mungkin berbeda dan kita berdua tidak akan salah).
Tersosauros
1
Coba ajukan pertanyaan yang jelas di muka, lalu sediakan materi pendukung.
Jay Elston

Jawaban:

22

The Konsep dari modul berbeda dari Instansiasi konsep itu.

Java selalu memiliki modul. Metode adalah modul, begitu juga kelas dan juga paket. Modul adalah unit organisasi di mana detail internal disembunyikan, dan yang berkomunikasi dengan modul lain melalui kontrak yang disepakati. Sebagai contoh, metode adalah modul karena memiliki internal tersembunyi (kode dan variabel lokal) dan kontrak (parameter dan tipe pengembalian). Modul dapat terdiri dari modul tingkat lebih rendah, misalnya kelas berisi metode.

Apa yang hilang pada Java inti (pra-9) adalah modul yang dapat digunakan . Semua jenis modul di atas bukanlah unit yang dapat digunakan yang dapat disalin. Java memang memiliki artefak yang dapat digunakan yang disebut file JAR, tetapi ini bukan modul karena mereka tidak memiliki enkapsulasi atau kontrak: pada saat runtime file JAR menghilang, semua digabung menjadi satu "classpath".

OSGi membahas kurangnya modul yang dapat digunakan pada tahun 1998 dengan konsep "bundel". Ini adalah file JAR secara fisik dan mengandung paket, tetapi OSGi mendefinisikan metadata tambahan bersama dengan sistem runtime untuk mendukung enkapsulasi dan kontrak pada tingkat itu.

Java 9 mengatasi kurangnya modul yang dapat digunakan dalam cara yang mirip dengan OSGi. Bisa dibilang ini sama sekali tidak perlu karena OSGi ada dan berfungsi, tapi itu diskusi yang sangat berbeda ...

Sayangnya Java 9 merusak perairan dengan menamai konsep modul baru hanya "modul". Ini tidak berarti bahwa metode, kelas dan paket berhenti menjadi modul! "Modul" J9 hanyalah contoh lain dari konsep modul . Seperti bundel OSGi, modul J9 terbuat dari paket dan merupakan artefak fisik (biasanya file JAR lagi) yang dapat disalin. Sistem runtime memahami dan menerimanya.

Rangkuman: ya modul dan paket J9 adalah gagasan yang terpisah secara semantik. Jelas Java harus mempertahankan konsep paket yang ada untuk kompatibilitas mundur. Perhatikan bahwa kata "paket" digunakan cukup berbeda di Jawa daripada di bahasa lain atau dalam sistem manajemen paket seperti RPM. Modul J9 baru (dan bundel OSGi) jauh lebih mirip paket dalam RPM daripada paket Java sebelumnya.

Neil Bartlett
sumber
Paket tidak memenuhi definisi modul Anda. Karena enkapsulasi yang lemah dan kurangnya sarana untuk mengagregasi paket-paket lain dan mempertajam visibilitasnya. Kelas bisa berisi kelas atau bidang bertingkat. Metode dapat berisi penutupan atau memanggil metode lain. Paket tidak dapat "berkomunikasi" dengan paket lain.
user2418306
Saya tidak setuju. Paket memiliki penyembunyian informasi (tipe akses default, metode dan bidang, alias paket-pribadi). Paket tentu saja "berkomunikasi" karena kode dalam suatu paket dapat meminta kode dalam paket lain. Ini dilakukan terhadap kontrak, yaitu tipe umum dan metode dari paket lainnya.
Neil Bartlett
Perhatikan bahwa kemampuan untuk mengumpulkan artefak modular pada tingkat yang sama (misalnya metode yang mengandung penutupan, kelas yang mengandung kelas bersarang) TIDAK membentuk bagian dari definisi modul saya. Jika Anda menganggap ini sebagai bagian penting dari definisi modul, maka "Java 9 modules" juga bukan modul.
Neil Bartlett
Saya tidak menyangkal bahwa paket memiliki informasi yang disembunyikan . Saya mengatakan bahwa itu tidak cukup. importbisa pasangan paket. Tetapi tidak ada cara untuk menyusun paket sebagai warga negara kelas satu. Kekurangan-kekurangan itu (dan keterbatasan OSGi) dijelaskan dalam JSR 376.
user2418306
Bisakah Anda menguraikan mengapa modul Java 9 juga bukan modul ?
user2418306
10

Biarkan saya bahaya pada jawaban, meskipun sebagian besar mungkin asumsi / membelah rambut / ocehan, dll.

Apakah mereka sama? Nah, ya dan tidak ada

Dari artikel JavaWorld ini tentang "Modularity in Java 9" :

Paket sebagai solusi modular

Paket mencoba menambahkan tingkat abstraksi ke lanskap pemrograman Java. Mereka menyediakan fasilitas untuk ruang nama kode yang unik dan konteks konfigurasi. Sayangnya, konvensi paket mudah dielakkan, seringkali mengarah ke lingkungan penggabungan waktu kompilasi yang berbahaya.

Seperti @ user2418306 (OP) mengisyaratkan, " modul adalah paket yang dilakukan dengan benar " . Modul dan paket di Java (pada Java 9, jelas) adalah (seperti yang diminta OP) secara semantik adalah hal yang sama. Yaitu, mereka adalah kumpulan bytecode JVM yang telah dikompilasi sebelumnya, dengan metadata lainnya - pada dasarnya , mereka adalah perpustakaan .

Nah apa bedanya?

Namun, perbedaannya ada pada metadata di dalam masing-masing. packageManifes Java , atau manifes JAR, tidak sering dikelola oleh pengembang perpustakaan, juga tidak memberikan kontrak yang pasti tentang apa yang disediakan oleh JAR / paket. Seperti yang dijelaskan di sini (artikel JavaWorld lagi) :

Apakah file JAR tidak cukup modular?

File JAR dan lingkungan penyebaran di mana mereka beroperasi sangat meningkatkan banyak konvensi penyebaran warisan yang tersedia. Tetapi file JAR tidak memiliki keunikan intrinsik, selain dari nomor versi yang jarang digunakan, yang disembunyikan dalam manifes .jar. File JAR dan manifes opsional tidak digunakan sebagai konvensi modularitas dalam lingkungan Java runtime. Jadi nama paket kelas dalam file dan partisipasi mereka dalam classpath adalah satu-satunya bagian dari struktur JAR yang meminjamkan modularitas ke lingkungan runtime.

Kata-kata kasar tentang bahasa / lingkungan lain, dll

Area lain yang dibahas dalam artikel itu adalah sistem seperti Maven , yang mengelola dependensi untuk Anda sebagai bagian dari proses pembangunan. Dari halaman ini di situs Apache Maven :

Manajemen ketergantungan:

Maven mendorong penggunaan repositori pusat JAR dan dependensi lainnya. Maven dilengkapi dengan mekanisme yang dapat digunakan klien proyek Anda untuk mengunduh semua JAR yang diperlukan untuk membangun proyek Anda dari repositori JAR pusat, seperti CPAN Perl. Ini memungkinkan pengguna Maven untuk menggunakan kembali JAR di seluruh proyek dan mendorong komunikasi antar proyek untuk memastikan bahwa masalah kompatibilitas mundur ditangani.

Sekarang berbicara tentang masa depan seolah-olah saya sudah ada di sana

Seperti yang disebutkan halaman itu , bahasa lain (seperti Perl), memiliki repositori paket (seperti CPAN ). Ini adalah tren yang meningkat (saya katakan karena saya merasa seperti itu, tanpa bukti tegas apa pun), selama sekitar sepuluh tahun terakhir. Alat-alat seperti permata Ruby , Python PyPi , dan manajer paket Node ( npm) dibangun berdasarkan ini untuk menyediakan cara yang konsisten untuk mengkonfigurasi lingkungan (baik pengembangan, pembuatan, pengujian, atau runtime, dll) dengan hal-hal yang benar (paket, modul, permata, gizmo, dll). Suatu ide (saya rasa) " dipinjam " dari sistem distribusi Linux® seperti Debian's apt , RedHat'srpm, dll. (Meskipun, jelas, telah berevolusi setidaknya satu generasi, dan menjadikan semuanya lebih baik.)

Modul Java , meskipun tidak perlu menambahkan apa pun yang belum dapat Anda lakukan, menjadikan tooling untuk dependensi / manajemen paket dan lingkungan build otomatis semuanya JAUH lebih mudah. Apakah itu membuat modul "lebih baik", saya menolak untuk mengatakan. : P

Tersosauros
sumber
1
Artikel baru berusia 1 tahun dan belum usang. Ini tinggal bagaimana versi adalah karakteristik mendasar dari sebuah modul. Modul jigsaw tidak akan memiliki info versi. Tidak ada dalam bidang pengelolaan ketergantungan akan berubah untuk pengguna akhir. Untuk alat membangun hal-hal akan jauh lebih sulit. Karena mereka perlu mendukung realitas paralel classpathdan modulepath. Dan lompati rintangan untuk mendukung pengujian unit. Premis yang dua konsepnya setara karena mewakili koleksi hal plus metadata terlalu berani untuk saya terima. Ditambah middleway, Anda tiba-tiba mengganti stoples untuk paket.
user2418306
Saya tidak mengatakan " dua konsep setara ", saya katakan mereka "secara semantik sama" - yang Anda tanyakan. Juga, Anda telah mengedit pertanyaan sejak saya menjawab untuk secara spesifik menyebutkan JSR-376 , sebagai lawan dari jigsaw yang adalah apa yang dikatakan sebelumnya: - /
Tersosauros
Jigsaw meliputi (mengimplementasikan) JSR-376. Pertanyaan masih terhubung ke keduanya, jadi tidak ada salahnya dilakukan. Kamus mendefinisikan kesetaraan sebagai kualitas atau keadaan memiliki makna yang sama. Dan secara semantik - berkenaan dengan makna. Saya minta maaf tetapi Anda menjadi jago tentang detail yang salah di sini. Anda mengatakan mereka setara. Tapi Anda tidak memberikan alasan apa pun. Sebagai gantinya Anda merujuk pada artikel yang menjelaskan bagaimana paket dan guci gagal menjadi modul. Tetapi modul yang akan datang gagal menjadi modul dari artikel juga. Mengklaim kesetaraan dan kemudian memberikan perbedaan antara 2 (3) itu saling bertentangan.
user2418306
Jawaban atas pertanyaan tidak boleh ya dan tidak. Entah dua konsep secara semantik setara atau tidak. Tolong jangan lobotomi komentar saya dan kembali ke pertanyaan awal. Apakah bahasa memerlukan kedua konsep atau ini adalah masalah khusus legacy java? Jika Anda perlu klarifikasi, saya senang membantu.
user2418306