JDK 16: Fitur baru di Java 16

Java Development Kit (JDK) 16 telah mencapai fase rampdown awal, yang berarti set fitur sekarang dibekukan, mulai 10 Desember 2020. Fitur baru di JDK 16 berkisar dari pratinjau kedua kelas tersegel hingga pencocokan pola hingga utas bersamaan- pemrosesan tumpukan untuk pengumpulan sampah.

JDK 16 akan menjadi acuan implementasi versi Java standar yang ditetapkan mengikuti JDK 15, yang tiba pada 15 September. Jadwal rilis yang diusulkan memiliki JDK 16 yang mencapai tahap rampdown kedua pada 14 Januari 2021, diikuti oleh kandidat rilis yang tiba pada 4 Februari dan 18 Februari 2021. Rilis produksi dijadwalkan akan diterbitkan pada 16 Maret 2021.

Tujuh belas proposal secara resmi menargetkan JDK 16 pada 10 Desember 2020. Kemampuan baru yang akan hadir di Java 16 meliputi:

  • Peringatan untuk proposal kelas berbasis nilai menetapkan kelas pembungkus primitif sebagai berbasis nilai dan tidak lagi menggunakan konstruktornya untuk dihapus, sehingga memicu peringatan penghentian baru. Peringatan diberikan tentang upaya yang tidak tepat untuk melakukan sinkronisasi pada instance kelas berbasis nilai apa pun di platform Java. Mendorong upaya ini adalah Proyek Valhalla, yang mengejar peningkatan signifikan pada model pemrograman Java dalam bentuk kelas primitif. Kelas primitif mendeklarasikan instance bebas identitas dan mampu membuat representasi sebaris atau diratakan, di mana instance dapat disalin secara bebas antara lokasi memori dan dienkode menggunakan nilai bidang instance.Desain dan implementasi kelas primitif di Java sekarang sudah cukup matang sehingga migrasi kelas tertentu dari platform Java ke kelas primitif dapat diantisipasi di rilis mendatang. Kandidat untuk migrasi secara informal ditetapkan sebagai kelas berbasis nilai dalam spesifikasi API.
  • Sebelumnya dipratinjau di JDK 15, class dan antarmuka tersegel membatasi class dan antarmuka lain yang dapat memperluas atau mengimplementasikannya. Tujuan dari rencana tersebut termasuk memungkinkan penulis kelas atau antarmuka untuk mengontrol kode yang bertanggung jawab untuk mengimplementasikannya, menyediakan cara yang lebih deklaratif daripada pengubah akses untuk membatasi penggunaan superclass, dan mendukung arah masa depan dalam pencocokan pola dengan memberikan dasar untuk analisis pola.
  • Enkapsulasi internal JDK yang kuat secara default, kecuali untuk API internal penting seperti misc.Unsafe. Pengguna dapat memilih enkapsulasi kuat santai yang telah menjadi default sejak JDK 9. Tujuan dari proposal ini termasuk meningkatkan keamanan dan pemeliharaan JDK, sebagai bagian dari Project Jigsaw, dan mendorong pengembang untuk bermigrasi dari menggunakan elemen internal ke menggunakan API standar sehingga bahwa baik pengembang maupun pengguna akhir dapat memperbarui dengan mudah ke rilis Java di masa mendatang. Proposal ini memiliki risiko utama bahwa kode Java yang ada akan gagal dijalankan. Pengembang didorong untuk menggunakan alat jdeps untuk mengidentifikasi kode yang bergantung pada elemen internal JDK dan beralih ke penggantian standar jika tersedia. Pengembang dapat menggunakan rilis yang sudah ada, seperti JDK 11, untuk menguji kode yang sudah ada dengan menggunakan --illegal-access=warnuntuk mengidentifikasi elemen internal yang diakses melalui refleksi, menggunakan  --illegal-access=debuguntuk menunjukkan kode yang salah, dan menguji dengan --illegal-access=deny.
  • Foreign linker API, menawarkan akses Java murni yang diketik secara statis ke kode native. API ini akan berada dalam tahap inkubator di JDK 16. Bersama dengan API akses memori asing yang diusulkan, API linker asing akan sangat menyederhanakan proses pengikatan ke perpustakaan asli yang rawan kesalahan. Rencana ini dimaksudkan untuk menggantikan JNI (Java Native Interface) dengan model pengembangan Java murni yang unggul, untuk menawarkan dukungan C, dan, seiring waktu, agar cukup fleksibel untuk mengakomodasi dukungan untuk platform lain, seperti 32-bit x86, dan fungsi asing yang ditulis dalam bahasa selain C, seperti C ++. Performa harus lebih baik daripada atau sebanding dengan JNI.
  • Memindahkan pemrosesan tumpukan benang ZGC (Z Garbage Collector) dari titik aman ke fase bersamaan. Tujuan dari rencana ini termasuk menghapus pemrosesan tumpukan benang dari titik aman ZGC; membuat pemrosesan tumpukan menjadi malas, kooperatif, bersamaan, dan inkremental; menghapus semua pemrosesan root per utas lainnya dari titik aman ZGC; dan menyediakan mekanisme untuk subsistem VM HotSpot lainnya untuk memproses tumpukan dengan malas. ZGC dimaksudkan untuk menjadikan jeda GC dan masalah skalabilitas di HotSpot sebagai masa lalu. Sejauh ini, operasi GC yang diskalakan dengan ukuran heap dan ukuran metaspace telah dipindahkan dari operasi titik aman dan ke fase bersamaan. Ini termasuk penandaan, relokasi, pemrosesan referensi, pembongkaran kelas, dan sebagian besar pemrosesan root.Satu-satunya aktivitas yang masih dilakukan di titik aman GC adalah bagian dari pemrosesan root dan operasi penghentian penandaan berbatas waktu. Akar ini termasuk tumpukan benang Java dan akar benang lainnya, dengan akar ini bermasalah karena berskala dengan jumlah benang. Untuk melampaui situasi saat ini, pemrosesan per utas, termasuk pemindaian tumpukan, harus dipindahkan ke fase bersamaan. Dengan rencana ini, biaya throughput dari latensi yang ditingkatkan seharusnya tidak signifikan dan waktu yang dihabiskan di dalam titik aman ZGC pada mesin biasa harus kurang dari satu milidetik.harus dipindahkan ke fase bersamaan. Dengan rencana ini, biaya throughput dari latensi yang ditingkatkan seharusnya tidak signifikan dan waktu yang dihabiskan di dalam titik aman ZGC pada mesin biasa harus kurang dari satu milidetik.harus dipindahkan ke fase bersamaan. Dengan rencana ini, biaya throughput dari latensi yang ditingkatkan seharusnya tidak signifikan dan waktu yang dihabiskan di dalam titik aman ZGC pada mesin biasa harus kurang dari satu milidetik.
  • Kemampuan metaspace elastis, yang mengembalikan memori metadata kelas (metaspace) VM HotSpot yang tidak digunakan lebih cepat ke OS, mengurangi jejak metaspace dan menyederhanakan kode metaspace untuk mengurangi biaya pemeliharaan. Metaspace mengalami masalah dengan penggunaan memori off-heap yang tinggi. Paket tersebut memanggil untuk mengganti pengalokasi memori yang ada dengan skema alokasi berbasis teman, menyediakan algoritme untuk membagi memori menjadi beberapa partisi untuk memenuhi permintaan memori. Pendekatan ini telah digunakan di tempat-tempat seperti kernel Linux dan akan membuatnya praktis untuk mengalokasikan memori dalam potongan yang lebih kecil untuk mengurangi overhead pemuat kelas. Fragmentasi juga akan berkurang. Selain itu, komitmen memori dari OS ke arena manajemen memori akan dilakukan secara malas, sesuai permintaan,untuk mengurangi jejak bagi loader yang dimulai dengan arena besar tetapi tidak segera menggunakannya atau mungkin tidak menggunakannya secara maksimal. Untuk sepenuhnya memanfaatkan elastisitas yang ditawarkan oleh alokasi buddy, memori metaspace akan disusun menjadi butiran berukuran seragam yang dapat dilakukan dan tidak terikat satu sama lain.
  • Pengaktifan fitur bahasa C ++ 14, untuk mengizinkan penggunaan kapabilitas C ++ 14 dalam kode sumber JDK C ++ dan memberikan panduan khusus tentang fitur mana yang dapat digunakan dalam kode VM HotSpot. Melalui JDK 15, fitur bahasa yang digunakan oleh kode C ++ di JDK telah dibatasi ke standar bahasa C ++ 98/03. Dengan JDK 11, kode sumber telah diperbarui untuk mendukung pembuatan dengan versi standar C ++ yang lebih baru. Ini termasuk kemampuan untuk membangun dengan versi terbaru dari kompiler yang mendukung fitur bahasa C ++ 11/14. Proposal ini tidak mengusulkan gaya atau perubahan penggunaan apa pun untuk kode C ++ yang digunakan di luar HotSpot. Namun untuk memanfaatkan fitur bahasa C ++, beberapa perubahan waktu build diperlukan, bergantung pada compiler platform.
  • API vektor dalam tahap inkubator, di mana JDK akan dilengkapi dengan modul inkubator, jdk.incubator.vector, untuk mengekspresikan penghitungan vektor yang dikompilasi menjadi instruksi perangkat keras vektor yang optimal pada arsitektur CPU yang didukung, untuk mencapai kinerja yang unggul ke penghitungan skalar yang setara. API vektor menyediakan mekanisme untuk menulis algoritme vektor kompleks di Java, menggunakan dukungan yang sudah ada di VM HotSpot untuk vektorisasi, tetapi dengan model pengguna yang membuat vektorisasi lebih dapat diprediksi dan kuat. Sasaran proposal termasuk menyediakan API yang jelas dan ringkas untuk mengekspresikan berbagai komputasi vektor, menjadi platform-agnostik dengan mendukung beberapa arsitektur CPU, dan menawarkan kompilasi dan kinerja runtime yang andal pada arsitektur x64 dan AArch64. Degradasi yang anggun juga merupakan tujuan,di mana komputasi vektor akan terdegradasi dengan baik dan masih berfungsi jika tidak dapat diekspresikan sepenuhnya pada waktu proses sebagai urutan instruksi vektor perangkat keras, baik karena arsitektur tidak mendukung beberapa instruksi atau arsitektur CPU lain tidak didukung.
  • Porting JDK ke platform Windows / AArch64. Dengan dirilisnya perangkat keras kelas server dan konsumen AArch64 (ARM64) baru, Windows / AArch64 telah menjadi platform penting karena adanya permintaan. Sementara porting itu sendiri sebagian besar sudah selesai, fokus proposal ini melibatkan integrasi port ke dalam repositori JDK jalur utama.
  • Porting dari JDK ke Alpine Linux dan ke distribusi Linux lain yang menggunakan musl sebagai library C utama mereka, pada arsitektur x64 dan AArch64. Musl adalah implementasi Linux dari fungsionalitas pustaka standar yang dijelaskan dalam standar ISO C dan Posix. Alpine Linux diadopsi secara luas dalam penerapan cloud, layanan mikro, dan lingkungan kontainer karena ukuran gambarnya yang kecil. Gambar Docker untuk Linux lebih kecil dari 6MB. Membiarkan Java keluar-of-the-box dalam pengaturan seperti itu akan memungkinkan Tomcat, Jetty, Spring, dan kerangka kerja populer lainnya untuk bekerja di lingkungan ini secara native. Dengan menggunakan jlink untuk mengurangi ukuran runtime Java, pengguna dapat membuat gambar yang lebih kecil yang disesuaikan untuk menjalankan aplikasi tertentu.
  • Menyediakan kelas record yang bertindak sebagai pembawa transparan untuk data yang tidak dapat diubah. Rekaman dapat dianggap tupel nominal. Rekaman dipratinjau di JDK 14 dan JDK 15. Upaya ini sebagai tanggapan atas keluhan bahwa Jawa terlalu bertele-tele atau terlalu banyak upacara. Sasaran dari rencana tersebut termasuk merancang konstruksi berorientasi objek yang mengekspresikan agregasi nilai sederhana, membantu pengembang fokus pada pemodelan data yang tidak dapat diubah daripada perilaku yang dapat diperluas, secara otomatis menerapkan metode berbasis data seperti equalsdan pengakses, dan mempertahankan prinsip-prinsip Java yang sudah lama ada seperti nominal mengetik.
  • Penambahan saluran soket domain-Unix, di mana dukungan soket Unix-domain (AF_UNIX) ditambahkan ke saluran soket dan API saluran soket server dalam paket nio.channels. Rencana tersebut juga memperluas mekanisme saluran yang diwariskan untuk mendukung saluran soket domain Unix dan saluran soket server. Soket domain Unix digunakan untuk komunikasi antar proses pada host yang sama. Mereka mirip dengan soket TCP / IP dalam banyak hal kecuali bahwa mereka dialamatkan oleh nama jalur sistem file daripada alamat IP dan nomor port. Tujuan dari kemampuan baru ini adalah untuk mendukung semua fitur saluran soket domain Unix yang umum di seluruh platform Unix utama dan Windows. Saluran soket domain-Unix akan berperilaku sama dengan saluran TCP / IP yang ada dalam hal perilaku baca / tulis, pengaturan koneksi, penerimaan koneksi masuk oleh server,dan multiplexing dengan saluran terpilih non-pemblokiran lainnya di selektor. Soket domain-Unix lebih aman dan lebih efisien daripada koneksi loopback TCP / IP untuk komunikasi antar-proses lokal.
  • API akses memori asing, yang memungkinkan program Java mengakses memori asing dengan aman di luar heap Java. Sebelumnya diinkubasi di JDK 14 dan JDK 15, API akses memori asing akan diinkubasi kembali di JDK 16, menambahkan penyempurnaan. Perubahan telah dilakukan termasuk pemisahan peran yang lebih jelas antara antarmuka MemorySegmentdan MemoryAddresses. Sasaran proposal ini termasuk menyediakan API tunggal untuk beroperasi pada berbagai jenis memori asing, termasuk memori heap bawaan, persisten, dan terkelola. API tidak boleh merusak keamanan JVM. Yang mendorong proposal tersebut adalah banyak program Java yang mengakses memori asing, seperti Ignite, Memcached, dan MapDB. Tetapi Java API tidak memberikan solusi yang memuaskan untuk mengakses memori asing.
  • Pencocokan pola untuk instanceofoperator, yang juga ditampilkan di JDK 14 dan JDK 15. Ini akan diselesaikan di JDK 16. Pencocokan pola memungkinkan logika umum dalam sebuah program, yaitu ekstraksi bersyarat komponen dari objek, untuk diekspresikan lebih ringkas dan dengan aman.
  • Menyediakan alat jpackage untuk mengemas aplikasi Java mandiri. Diperkenalkan sebagai alat inkubasi di JDK 14, jpackage tetap dalam inkubasi di JDK 15. Dengan JDK 16, jpackage beralih ke produksi, mendukung format paket asli untuk memberikan pengalaman instalasi yang alami kepada pengguna dan memungkinkan parameter waktu peluncuran ditentukan pada waktu pengemasan. Formatnya termasuk msi dan exe di Windows, pkg dan dmg di MacOS, serta deb dan rpm di Linux. Alat tersebut dapat dipanggil langsung dari baris perintah atau secara terprogram. Alat pengemasan yang baru mengatasi situasi di mana banyak aplikasi Java perlu diinstal pada platform asli dengan cara kelas satu, daripada ditempatkan di jalur kelas atau jalur modul. Diperlukan paket yang dapat diinstal yang sesuai untuk platform asli.
  • Migrasi repositori kode sumber OpenJDK dari Mercurial ke Git. Mendorong upaya ini adalah keuntungan dalam ukuran metadata sistem kontrol versi serta alat dan hosting yang tersedia.
  • Migrasi ke GitHub, terkait dengan migrasi Mercurial-to-Git, dengan repositori kode sumber JDK 16 berada di situs berbagi kode populer. Rilis fitur JDK dan rilis pembaruan JDK untuk Java 11 dan yang lebih baru akan menjadi bagian dari paket ini. Transisi ke Git, GitHub, dan Skara untuk Mercurial JDK dan JDK-sandbox dilakukan pada tanggal 5 September dan terbuka untuk kontribusi.  

Build akses awal JDK 16 untuk Linux, Windows, dan MacOS dapat ditemukan di jdk.java.net. Seperti JDK 15, JDK 16 akan menjadi rilis jangka pendek, didukung selama enam bulan. JDK 17, yang jatuh tempo pada September 2021, akan menjadi rilis dukungan jangka panjang (LTS) yang akan menerima dukungan selama beberapa tahun. Rilis LTS saat ini, JDK 11, dirilis pada September 2018.