Kelas Tersembunyi, Kelas Tertutup, Blok Teks , Catatan, dan EdDSA: JDK 15 memiliki banyak nilai.
Seperti yang dikatakan salah satu ungkapan favorit saya, ada banyak kebaikan cokelat yang kaya di Java 15 . Versi baru (dirilis 15 September 2020) mencakup 14 perubahan penting (JEP) yang bertujuan untuk meningkatkan JDK. Artikel ini memberikan gambaran umum singkat tentang produk baru berdasarkan informasi yang terdapat di JEP.
14 JEP dapat dibagi menjadi lima kelompok. Untuk studi yang lebih detail, lihat dokumentasi untuk masing-masingnya.
Fungsi baru yang akan membuat Anda takjub:
- JEP 339: Edwards Curve Digital Signature Algorithm (EdDSA)
- JEP 371: Kelas Tersembunyi
Penambahan fungsionalitas standar Java SE yang ada:
- JEP 378: Blok Teks
- JEP 377: Pengumpul Sampah ZGC
- JEP 379: Shenandoah - Pengumpul Sampah Jeda Rendah
Perbaikan pada fungsionalitas Java SE yang lama:
- JEP 373: Perbaikan DatagramSocket API yang sudah tidak digunakan lagi
Kami menantikan produk baru:
- JEP 360: Kelas Tertutup (Pratinjau)
- JEP 375: Pencocokan Pola untuk instanceof (Pratinjau Kedua)
- JEP 384: Entri (Konsep Kedua)
- JEP 383: API Akses Memori Eksternal (Fungsi Inkubator Kedua)
Penghapusan dan penghentian dukungan:
- JEP 372: Nashorn JavaScript Engine
- JEP 374:
- JEP 381: Solaris SPARC
- JEP 385: RMI
,
Edwards Curve Digital Signature Algorithm ( JEP 339 ). Saya akan menjadi orang pertama yang mengakui bahwa Edwards-Curve Digital Signature Algorithm (EdDSA) sedikit di luar pengetahuan saya tentang enkripsi. Oke, saya sama sekali tidak tahu tentang itu. Namun, JEP ini dirancang sebagai platform implementasi EdDSA independen dengan kinerja lebih baik daripada implementasi C yang ada, ECDSA.
Menurut dokumentasi JDK, EdDSA adalah skema tanda tangan kurva elips modern yang memiliki beberapa keunggulan dibandingkan yang sudah ada di JDK.
Tujuan implementasi:
- Tujuan utama dari JEP ini adalah untuk mengimplementasikan skema tanda tangan seperti yang distandarisasi dalam RFC 8032 . Namun, skema baru tidak menggantikan ECDSA.
- - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
- , . .
Sekarang Anda tahu lebih banyak daripada saya. Nantikan artikel Majalah Java yang menjelaskan EdDSA segera.
Kelas Tersembunyi ( JEP 371 ) adalah kelas yang tidak bisa dipanggil secara langsung oleh bytecode kelas lain. Mereka dimaksudkan untuk digunakan oleh kerangka kerja yang secara dinamis membuat kelas pada waktu proses dan menggunakannya secara tidak langsung melalui mekanisme refleksi. Kelas yang dibuat secara dinamis mungkin hanya diperlukan untuk waktu yang terbatas, jadi menyimpannya selama kelas yang dibuat secara statis dapat meningkatkan jejak memori yang tidak perlu.
Kelas yang dibuat secara dinamis juga tidak dapat dideteksi. Menemukan kelas-kelas seperti itu berdasarkan nama akan merugikan, karena akan merusak tujuannya, yaitu bahwa mereka hanyalah sebuah detail implementasi dari kelas yang dibuat secara statis.
Rilis kelas tersembunyi meletakkan dasar bagi pengembang untuk berhenti menggunakan API non-standar sun.misc.Unsafe :: defineAnonymousClass . Oracle bermaksud untuk menghapus dan menghapus kelas ini di masa mendatang.
Penambahan standar Java SE yang ada
Blok teks ( JEP 378 ) yang berasal dari Proyek Amber akhirnya dirilis setelah dua versi awal di JDK 13 dan 14. Tujuan pembuatannya adalah keinginan pengembang untuk mengurangi kesulitan dalam mendeklarasikan dan menggunakan literal string multi-baris di Java.
Blok teks secara otomatis memformat string dengan cara yang dapat diprediksi, tetapi jika itu tidak cukup, pengembang dapat mengambil alih pemformatan. Versi kedua dari fungsionalitas awal memperkenalkan dua urutan pelolosan baru untuk menangani baris dan spasi baru. Misalnya, \ <line-terminator> secara eksplisit menekan penyisipan karakter baris baru.
Sebelumnya, untuk mencetak satu baris teks yang panjang, Anda harus menulis seperti ini:
Menggunakan \ membuat kode lebih mudah dibaca:
Urutan pelolosan dapat mencegah spasi tambahan dihapus. Jadi, teks berikut mewakili tiga baris, yang masing-masing terdiri dari tepat lima karakter (di baris tengah, sesuai dengan warna hijau, \ s tidak digunakan, karena sudah berisi lima karakter).
Pengumpul sampah ZGC ( JEP 377 ) diperkenalkan di JDK 11 sebagai fitur eksperimental. Sekarang sudah mendapat status resmi. ZGC adalah pengumpul sampah paralel, berkemampuan NUMA, dan skalabel dengan latensi pengumpulan sampah rendah (kurang dari 10 milidetik bahkan pada tumpukan multi-terabyte). Waktu jeda rata-rata, seperti yang diuji oleh Oracle, kurang dari 1 milidetik, dan maksimumnya kurang dari 2 milidetik. Gambar 1 membandingkan pengumpul sampah paralel Java, G1, dan ZGC, dengan waktu jeda ZGC yang ditingkatkan dengan faktor 10.
Gambar 1. Perbandingan waktu jeda pengumpul sampah
Namun, untuk banyak beban kerja, G1 (yang masih default) mungkin sedikit lebih cepat daripada ZGC. Selain itu, untuk heap yang sangat kecil, seperti yang hanya berukuran beberapa ratus megabyte, G1 juga bisa lebih cepat. Oleh karena itu, Anda disarankan untuk menjalankan pengujian Anda sendiri dengan beban Anda untuk melihat pengumpul sampah mana yang akan digunakan.
Penting: Karena ZGC tidak lagi eksperimental (disertakan dalam build Oracle OpenJDK dan Oracle JDK), Anda tidak perlu lagi menggunakan -XX: + UnlockExperimentalVMOptions untuk mengaktifkannya.
Shenandoah ( JEP 379) Merupakan varian lain dari pengumpul sampah yang tersedia di beberapa build OpenJDK. Ini telah menjadi percobaan sejak JDK 12. Sekarang, seperti dengan ZGC, XX: + UnlockExperimentalVMOptions tidak diperlukan.
Modernisasi fungsionalitas Java SE warisan
Mengolah kembali DatagramSocket API ( JEP 373 ). Anggap ini pada dasarnya adalah pemfaktoran ulang beberapa kode Jurassic, karena JEP ini menggantikan implementasi lama, yang sulit dipelihara dari java.net.DatagramSocket dan java.net.MulticastSocket API dengan implementasi modern yang lebih sederhana yang mudah dipelihara dan di-debug, dan yang akan bekerja dengan aliran virtual Project Loom.
Karena ada banyak kode yang menggunakan API lama (sejak JDK 1.0), implementasi yang sudah usang tidak akan dihapus. Faktanya, properti sistem khusus JDK baru, jdk.net.usePlainDatagramSocketImpl, mengonfigurasi JDK untuk menggunakan implementasi yang tidak digunakan lagi jika pemfaktoran ulang API menyebabkan masalah dengan uji regresi atau dalam beberapa kasus.
Kami sangat menantikan produk baru
Kelas Tertutup ( JEP 360 ). Versi praproduksi pertama dibuat di Project Amber. Kelas dan antarmuka yang disegel membatasi ekstensi atau implementasinya ke kelas lain. Mengapa ini penting? Pengembang mungkin ingin mengelola kode yang bertanggung jawab untuk mengimplementasikan kelas atau antarmuka tertentu. Class yang disegel menyediakan cara yang lebih deklaratif daripada pengubah akses untuk membatasi penggunaan superclass. Misalnya:
Tujuan penyegelan kelas adalah untuk memberi tahu kode klien subkelas mana yang diizinkan. Bagaimanapun, mungkin ada kasus penggunaan di mana definisi asli dari sebuah kelas (atau antarmuka) diharapkan benar-benar lengkap, dan di mana pengembang tidak mengizinkannya untuk diperpanjang di luar kendali - hanya kelas yang ditentukan secara eksplisit yang bisa.
Ada beberapa batasan untuk kelas tertutup:
- Kelas tertutup dan subkelas yang diizinkan harus berada dalam modul yang sama. Jika mereka dideklarasikan dalam modul tanpa nama, maka mereka harus ditempatkan dalam paket yang sama
- Setiap subclass yang diizinkan harus secara langsung memperluas kelas yang disegel
- , , , — final, sealed nonsealed ( )
Pencocokan pola untuk instanceof ( JEP 375 ). Pratinjau kedua adalah pengembangan lain dari Project Amber. Versi awal pertama dari fungsionalitas tersebut ada di Java 14 dan tidak ada perubahan dibandingkan dengan itu.
Tujuannya adalah untuk meningkatkan Java melalui pencocokan pola untuk operator instanceof. Hal ini memungkinkan Anda untuk mengekspresikan logika umum secara lebih ringkas dan aman dalam program, yaitu ekstraksi bersyarat komponen dari objek. Izinkan saya merujuk Anda ke artikel bagus Mal Gupta " Pencocokan Pola untuk contoh di Java 14 " sebagai contoh.
Entri ( JEP 384), draf kedua. Record adalah class yang bertindak sebagai pembawa transparan dari data yang tidak dapat diubah. JEP baru mencakup klarifikasi berdasarkan umpan balik komunitas dan mendukung beberapa bentuk tambahan baru dari kelas dan antarmuka lokal. Entri juga datang dari Project Amber.
Rekaman adalah konstruksi berorientasi objek yang mengekspresikan agregasi nilai sederhana. Dengan demikian, mereka membantu pemrogram fokus pada pemodelan data yang tidak dapat diubah daripada perilaku yang dapat diperluas. Rekaman secara otomatis menerapkan metode berbasis data seperti sederajat dan pengakses. Entri juga mempertahankan prinsip-prinsip Java lama seperti pengetikan nominal dan kompatibilitas migrasi. Dengan kata lain, mereka mempermudah kode dan membaca kelas yang berisi data yang tidak dapat diubah.
External Memory Access ( JEP 383 ) adalah versi inkubator kedua dari API yang memungkinkan program Java mengakses memori eksternal dengan aman dan efisien di luar heap Java. Tujuannya adalah untuk mulai mengganti java.nio.ByteBuffer dan sun.misc.Unsafe. Ini adalah bagian dari proyek Panama yang meningkatkan komunikasi antara Java dan API lainnya.
JEP dengan tepat mendeskripsikan kebutuhan akan inovasi ini sebagai berikut:
Dalam hal mengakses memori eksternal, pengembang dihadapkan pada dilema - haruskah mereka memilih jalur yang aman, tetapi terbatas (dan mungkin kurang efisien), seperti ByteBuffer API, atau haruskah mereka melepaskan jaminan keamanan dan mengadopsi API Tidak Aman yang berbahaya dan tidak didukung?
JEP ini memperkenalkan API yang aman, dapat dipelihara, dan efisien untuk mengakses memori eksternal. Dengan memberikan solusi yang ditargetkan untuk masalah akses memori eksternal, pengembang akan terbebas dari batasan dan bahaya API yang ada. Mereka juga akan mendapatkan kinerja yang lebih baik karena API baru dirancang dari awal dengan mempertimbangkan pengoptimalan JIT.
Penghapusan dan akhir dukungan
Tak satu pun dari keputusan ini yang kontroversial.
Penghapusan mesin JavaScript Nashorn ( JEP 372 ). Mesin ini, API dan alat jjs-nya tidak digunakan lagi di Java 11. Saatnya mengucapkan selamat tinggal.
Menonaktifkan dan Mengecualikan Penguncian Cadangan ( JEP 374 ) menghapus teknik pengoptimalan lama yang digunakan di HotSpot JVM untuk mengurangi biaya tambahan yang terkait dengan penguncian yang tidak dicentang. Penguncian ini secara historis menghasilkan peningkatan kinerja yang signifikan dibandingkan metode penguncian konvensional, tetapi peningkatan kinerja yang terlihat di masa lalu jauh lebih tidak terbukti saat ini. Biaya menjalankan instruksi atom pada prosesor modern telah turun.
Penguncian yang berlebihan telah menghasilkan banyak kode yang kompleks, dan kerumitan ini mencegah tim pengembangan Java untuk membuat perubahan signifikan pada mesin sinkronisasi. Dengan menonaktifkan kunci, dan menyerahkannya kepada programmer untuk mengaktifkannya kembali, tim pengembangan Java berharap dapat menentukan apakah akan bijaksana untuk menghapusnya seluruhnya di rilis mendatang.
Menghapus port Solaris dan SPARC ( JEP 381 ). Dalam kasus ini, semua kode sumber khusus untuk sistem operasi Solaris dan arsitektur SPARC akan dihapus. Tidak ada lagi yang bisa dikatakan.
Kecualikan aktivasi RMI untuk penginstalan nanti ( JEP 385). Menyederhanakan Java dengan menghapus bagian usang dari memanggil metode jarak jauh yang opsional di Java 8.
Penggunaan aktivasi RMI dikurangi dan dikurangi. Tim Java tidak melihat bukti bahwa aplikasi baru telah ditulis menggunakannya, dan ada bukti bahwa sangat sedikit aplikasi yang ada yang menggunakan aktivasi RMI. Pencarian berbagai basis kode open source menemukan hampir tidak ada penyebutan API yang terkait dengannya. Tidak ada laporan kesalahan aktivasi RMI yang dibuat secara eksternal selama beberapa tahun.
Mendukung aktivasi RMI sebagai bagian dari platform Java memiliki biaya pemeliharaan yang berkelanjutan. Ini menambah kompleksitas RMI. Anda dapat menghapus aktivasi RMI tanpa mempengaruhi seluruh RMI. Menghapusnya tidak mengurangi nilai pengembang Java, tetapi mengurangi biaya pemeliharaan jangka panjang JDK.
Kesimpulan
Java 15 melanjutkan siklus rilis enam bulannya dan merupakan rilis berukuran sedang yang berguna bagi sebagian besar pengembang.