Tiga akronim ini sering diucapkan berdampingan: JDK, JRE, dan JVM. Ketiganya membentuk tiga lapisan platform Java, dari mesin yang paling dalam sampai kotak peralatan pengembang di lapisan terluar. Salah mengenali lapisannya berakibat salah memilih unduhan ketika memasang Java, atau salah menafsirkan pesan error yang muncul. Chapter ini membedah isi tiap lapisan, membandingkan ketiganya dalam satu tabel, menjelaskan mengapa JRE terpisah tidak lagi didistribusikan sejak Java 11, lalu menginventarisasi alat-alat penting di folder bin JDK.
JVM Mesin yang Menjalankan Bytecode #
Java Virtual Machine (JVM) adalah program yang membaca bytecode dari berkas .class lalu mengeksekusinya. JVM tidak memahami sintaks Java; inputnya adalah bytecode — instruksi netral terhadap prosesor dan sistem operasi. Di dalam JVM terjadi banyak hal sekaligus: class loader memuat class, bytecode diverifikasi demi keamanan, garbage collector memungut memori objek yang tidak terpakai, dan JIT compiler menerjemahkan kode yang sering dieksekusi menjadi instruksi mesin asli. Spesifikasi JVM didefinisikan dalam dokumen resmi Java Virtual Machine Specification, dan implementasi paling banyak dipakai adalah HotSpot yang tersedia di hampir semua distribusi JDK.
JRE Lingkungan untuk Menjalankan Aplikasi #
Java Runtime Environment (JRE) adalah JVM ditambah pustaka inti yang dibutuhkan program agar bisa berjalan — modul java.base berisi java.lang, java.util, java.io, hingga java.math. JRE ditujukan bagi pengguna akhir aplikasi Java yang cukup menjalankan program tanpa mengompilasi apa pun. Pada era sebelum Java 11, JRE didistribusikan sebagai paket pemasangan terpisah yang lebih kecil dari JDK: pengguna biasa memasang JRE, pengembang memasang JDK. Sejak era modul (Java 9) dan rilis Java 11, pembatasan tersebut berubah — kita bahas alasannya di bagian akhir chapter ini.
JDK Perangkat Lengkap untuk Pengembang #
Java Development Kit (JDK) adalah JRE ditambah seluruh perangkat pengembangan: compiler javac, generator dokumentasi javadoc, alat pengemasan jar, REPL jshell, hingga perakit runtime jlink. Sebagai pengembang, kita memasang JDK karena menulis kode — kompilasi adalah aktivitas harian. Diagram relasi ketiganya pada era Java 8 dapat digambarkan berjenjang: JDK memuat JRE, dan JRE memuat JVM. Sejak Java 9 modul JPMS merapikan pustaka menjadi modul-modul, dan sejak Java 11 paket JDK memuat semuanya secara langsung tanpa subfolder jre.
Perbandingan Singkat #
| Aspek | JVM | JRE | JDK |
|---|---|---|---|
| Fungsi utama | Mengeksekusi bytecode | Menjalankan aplikasi jadi | Mengembangkan aplikasi |
| Isi | Interpreter, JIT, GC, class loader | JVM + pustaka inti | JRE + javac dan alat lain |
| Dipakai oleh | (bagian dari JRE/JDK) | Pengguna akhir | Pengembang |
Bisa mengompilasi .java | Tidak | Tidak | Ya |
| Status distribusi | Selalu terpasang di dalam | Tidak lagi terpisah sejak Java 11 | Bentuk unduhan utama |
Ketiga baris pertama menjelaskan mengapa tutorial-tutorial lawas menyuruh pengguna akhir memasang JRE saja: pada masalah “menjalankan aplikasi”, JRE memang memadai. Baris terakhir mencatat pergeseran zaman: hari ini satu-satunya bentuk unduhan resmi adalah JDK, dan kebutuhan runtime ramping dialihkan ke jlink.
Mengapa JRE Terpisah Hilang Sejak Java 11 #
Ada dua alasan yang saling menguatkan. Pertama, pustaka Java 9 ke atas dipecah menjadi modul-modul (JEP 220 menghapus berkas raksasa rt.jar), sehingga runtime dapat dirakit sesuai kebutuhan — tidak ada alasan membagikan satu paket JRE berukuran besar untuk semua aplikasi. Kedua, alat jlink (JEP 282) dapat menggabungkan modul-modul terpilih plus aplikasi kita menjadi satu custom runtime image yang berdiri sendiri: hasilnya bisa jauh lebih kecil dari JRE penuh dan tidak memerlukan Java terpasang di komputer sasaran. Pola ini sangat pas untuk container dan aplikasi desktop yang dikemas dengan jpackage. Sejak Java 11, Oracle dan distribusi lain berhenti menyediakan pengunduh JRE terpisah; pengguna cukup memasang JDK, atau memakai runtime image buatan jlink.
Alat-Alat di Folder bin JDK #
Folder bin pada pemasangan JDK berisi 30-an program kecil. Sebagian besar kita sentuh hampir setiap hari, sebagian lagi hidup di ranah spesialis. Berikut daftar yang paling relevan untuk tahap belajar:
| Alat | Fungsi |
|---|---|
javac | Mengompilasi berkas .java menjadi berkas .class berisi bytecode |
java | Menjalankan class hasil kompilasi; sejak Java 11 juga bisa mengeksekusi berkas .java langsung |
jshell | REPL interaktif untuk mencoba potongan kode tanpa membuat berkas |
jar | Mengemas class dan resource ke dalam arsip JAR |
javadoc | Menghasilkan dokumentasi HTML dari komentar berformat pada kode |
javap | Membongkar isi berkas .class — berguna mempelajari bytecode |
jlink | Merakit custom runtime image dari modul terpilih |
jpackage | Mengemas aplikasi Java menjadi installer desktop |
jdb | Debugger berbasis baris perintah |
jcmd, jmap, jstack, jstat | Diagnostik JVM saat program berjalan: perintah, memori, thread, statistik |
Menilik Runtime dari Dalam Program #
Konsep di atas bukan sekadar teori — program Java bisa menanyakan identitas runtime yang menjalankannya lewat property sistem dan API modul. Program berikut memeriksa versi JVM, nama implementasi mesin, distribusi yang membangunnya, sampai jumlah modul yang dimuat saat JVM dinyalakan:
public class LapisanRuntime {
public static void main(String[] args) {
// Property sistem dilaporkan oleh JVM yang sedang berjalan
System.out.println("java.version : " + System.getProperty("java.version"));
System.out.println("java.vm.name : " + System.getProperty("java.vm.name"));
System.out.println("java.vendor : " + System.getProperty("java.vendor"));
// Pustaka standar dimuat JVM sebagai kumpulan modul
System.out.println("Class String tinggal di modul : "
+ String.class.getModule().getName());
System.out.println("Modul aktif di boot layer : "
+ ModuleLayer.boot().modules().size());
}
}Output yang Dihasilkan:
java.version : 25.0.4.1
java.vm.name : OpenJDK 64-Bit Server VM
java.vendor : Eclipse Adoptium
Class String tinggal di modul : java.base
Modul aktif di boot layer : 61Mari kita telaah hubungan tiap baris dengan tiga lapisan platform:
- Baris 5-7 (
System.getProperty(...)): membaca property yang dilaporkan JVM.java.versionmenunjukkan versi JDK,java.vm.namemenunjukkan implementasi mesin virtual (HotSpot untuk keluarga OpenJDK), danjava.vendormenunjukkan distribusi yang membangunnya — pada lingkungan Course ini, Eclipse Adoptium (Temurin). - Baris 10-11 (
String.class.getModule().getName()): menanyakan modul tempat classStringtinggal. Hasilnyajava.base— modul inti yang selalu hadir, bukti bahwa pustaka standar tersusun sebagai modul, bukan satu berkas raksasa seperti erart.jar. - Baris 12-13 (
ModuleLayer.boot().modules().size()): menghitung modul yang dimuat JVM pada boot layer ketika program dinyalakan. Angka 61 adalah jumlah untuk JDK 25 — angka pastinya bergantung pada versi JDK, tetapi nilainya tetap sama untuk versi yang sama.
Kini kita mengenal isi kotak peralatannya. Pertanyaan berikutnya yang wajar: apa yang sebenarnya terjadi di antara menekan tombol kompilasi dan program tercetak di layar? Chapter Cara Kerja Java mengikuti perjalanan satu berkas .java melewati javac, berkas .class, class loader, hingga eksekusi di dalam JVM.
Referensi #
Berkas Sumber
Berkas pendukung halaman ini dapat diunduh dan dijalankan langsung sesuai penjelasan di atas.
LapisanRuntime.java
Unduh berkaspublic class LapisanRuntime {
public static void main(String[] args) {
// Property sistem dilaporkan oleh JVM yang sedang berjalan
System.out.println("java.version : " + System.getProperty("java.version"));
System.out.println("java.vm.name : " + System.getProperty("java.vm.name"));
System.out.println("java.vendor : " + System.getProperty("java.vendor"));
// Pustaka standar dimuat JVM sebagai kumpulan modul
System.out.println("Class String tinggal di modul : "
+ String.class.getModule().getName());
System.out.println("Modul aktif di boot layer : "
+ ModuleLayer.boot().modules().size());
}
}