Rilis Berbasis Waktu Java

1. Perkenalan

Pada artikel ini, kita akan membahas rilis baru berbasis waktu Java dan dampaknya pada semua jenis pengembang.

Perubahan pada jadwal rilis termasuk memperbarui pengiriman fitur dan level dukungan untuk versi Java. Secara keseluruhan, perubahan ini sangat berbeda dengan Java yang telah didukung oleh Oracle sejak 2010.

2. Mengapa Rilis Enam Bulan?

Bagi kita yang terbiasa dengan irama rilis lambat secara historis Jawa, ini adalah keberangkatan yang cukup signifikan. Mengapa terjadi perubahan yang begitu dramatis?

Awalnya, Java mendefinisikan rilis utamanya seputar pengenalan fitur besar. Ini memiliki kecenderungan untuk menciptakan penundaan, seperti yang kita semua alami dengan Java 8 dan 9. Ini juga memperlambat inovasi bahasa sementara bahasa lain dengan siklus umpan balik yang lebih ketat berkembang.

Sederhananya, periode rilis yang lebih pendek mengarah pada langkah maju yang lebih kecil dan lebih mudah dikelola. Dan fitur yang lebih kecil lebih mudah diadopsi.

Pola seperti itu berpasangan dengan baik dalam kondisi saat ini dan memungkinkan pengembangan JDK untuk bekerja dalam metodologi tangkas yang mirip dengan komunitas yang didukungnya. Selain itu, ini membuat Java lebih kompetitif dengan runtime seperti NodeJS dan Python.

Tentu saja, kecepatan yang lebih lambat juga memiliki manfaatnya, sehingga siklus rilis enam bulan juga berperan dalam kerangka kerja Dukungan Jangka Panjang yang lebih besar, yang akan kita lihat di Bagian 4.

3. Perubahan Nomor Versi

Aspek mekanis dari perubahan ini adalah skema nomor versi baru.

3.1. JEP 223 Version-String Scheme

Kita semua akrab dengan yang lama, yang dikodifikasi dalam JEP 223. Skema ini membuat nomor versi bertambah dan menyampaikan informasi tambahan.

 Actual Hypothetical Release Type long short ------------ ------------------------ Security 2013/06 1.7.0_25-b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60

Jika kita menjalankan java -version pada JVM untuk versi 8 atau lebih lama, kita akan melihat sesuatu seperti:

>java -version java version "1.6.0_27" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)

Dalam hal ini, kami mungkin menebak ini untuk Java 6, yang benar, dan pembaruan ke-27, yang salah. Skema penomoran tidak seintuitif yang terlihat.

Rilis minor adalah kelipatan 10, dan rilis keamanan mengisi yang lainnya. Biasanya, kita akan melihat string pendek ditambahkan ke instalasi lokal kita, seperti JDK 1.8u174. Rilis berikutnya mungkin JDK 1.8u180, yang akan menjadi rilis minor dengan perbaikan baru.

3.2. Skema Versi-String Baru

Skema string versi baru akan " menyusun ulang nomor versi untuk tidak menyandikan kompatibilitas dan signifikansi tetapi, lebih pada, berlalunya waktu, dalam hal siklus rilis, " menurut Mark Reinhold di JEP.

Mari kita lihat beberapa:

9.0.4 11.0.2 10.0.1

Sekilas ini tampak seperti versi semantik; Namun, bukan itu masalahnya.

Dengan pembuatan versi semantik, struktur tipikal adalah $ MAJOR. $ MINOR. $ PATCH , tetapi struktur versi baru Java adalah:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$ FITUR adalah apa yang mungkin kita anggap sebagai versi utama , tetapi akan bertambah setiap enam bulan terlepas dari jaminan kompatibilitas. Dan $ PATCH untuk rilis pemeliharaan. Tapi, disinilah kemiripan berhenti.

Pertama, $ INTERIM adalah placeholder, disediakan oleh Oracle untuk kebutuhan masa depan. Untuk saat ini, nilainya akan selalu nol.

Dan kedua, $ UPDATE berbasis waktu seperti $ FEATURE, diperbarui setiap bulan setelah rilis fitur terbaru.

Dan akhirnya, angka nol di belakangnya akan terpotong.

Ini berarti 11 adalah nomor rilis untuk Java 11, dirilis pada September 2018, 11.0.1 adalah rilis pembaruan bulanan pertama pada bulan Oktober, dan 11.0.1.3 adalah rilis patch ketiga hipotetis dari versi Oktober.

4. Distribusi Versi Ganda

Selanjutnya, mari kita lihat cara memilih versi yang tepat.

4.1. Stabilitas

Sederhananya, Java sekarang memiliki saluran cepat, setiap enam bulan, dan saluran lambat, setiap tiga tahun. Setiap rilis tahun ketiga disebut rilis LTS.

Di saluran cepat, bahasa merilis fitur dalam inkubasi. Fitur bahasa ini stabil dalam rilis LTS.

Jadi, bagi perusahaan yang dapat merangkul volatilitas dengan imbalan menggunakan fitur baru, mereka dapat menggunakan saluran cepat. Untuk perusahaan yang menghargai stabilitas dan menunggu untuk meningkatkan, mereka dapat meningkatkan di setiap rilis LTS.

Eksperimen dengan versi JDK memungkinkan pengembang menemukan yang paling cocok.

4.2. Dukung

Ada juga, tentu saja, soal dukungan. Sekarang setelah dukungan Java 8 berakhir, apa yang harus kita lakukan?

Dan seperti yang dibahas sebelumnya, jawabannya hadir dalam versi LTS, Java 11 menjadi rilis LTS terbaru dan 17 menjadi yang berikutnya . Pembaruan akan tersedia dan didukung oleh vendor seperti Oracle dan Azul.

Jika kami dapat mempercayai dukungan komunitas, maka Redhat, IBM, dan lainnya telah menyatakan dukungan mereka untuk menerapkan perbaikan bug untuk OpenJDK. Selain itu, proyek AdoptOpenJDK menyediakan binari bawaan untuk OpenJDK.

4.3. Perizinan

Satu area kebingungan untuk beberapa adalah perbedaan antara OpenJDK dan Oracle JDK.

Sebenarnya, mereka hampir identik, hanya berbeda di mana perbaikan bug dan patch keamanan telah diambil, menurut Brian Goetz.

OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.

4.4. Fragmentation

With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.

Of course, containerization could help address this. From Docker and CoreOS to Red Hat's OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.

5. Conclusion

Kesimpulannya, kami dapat mengharapkan lebih banyak dari tim Java di Oracle dengan rilis reguler Java setiap enam bulan. Sebagai pengembang Java, prospek fitur bahasa baru setiap enam bulan sangat menarik.

Mari kita ingat beberapa implikasi saat kita memutuskan apa saluran peningkatan kita jika kita membutuhkan dukungan dan lisensi, dan bagaimana mengatasi fragmentasi.