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 #

AspekJVMJREJDK
Fungsi utamaMengeksekusi bytecodeMenjalankan aplikasi jadiMengembangkan aplikasi
IsiInterpreter, JIT, GC, class loaderJVM + pustaka intiJRE + javac dan alat lain
Dipakai oleh(bagian dari JRE/JDK)Pengguna akhirPengembang
Bisa mengompilasi .javaTidakTidakYa
Status distribusiSelalu terpasang di dalamTidak lagi terpisah sejak Java 11Bentuk 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:

AlatFungsi
javacMengompilasi berkas .java menjadi berkas .class berisi bytecode
javaMenjalankan class hasil kompilasi; sejak Java 11 juga bisa mengeksekusi berkas .java langsung
jshellREPL interaktif untuk mencoba potongan kode tanpa membuat berkas
jarMengemas class dan resource ke dalam arsip JAR
javadocMenghasilkan dokumentasi HTML dari komentar berformat pada kode
javapMembongkar isi berkas .class — berguna mempelajari bytecode
jlinkMerakit custom runtime image dari modul terpilih
jpackageMengemas aplikasi Java menjadi installer desktop
jdbDebugger berbasis baris perintah
jcmd, jmap, jstack, jstatDiagnostik 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:

text
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    : 61

Mari kita telaah hubungan tiap baris dengan tiga lapisan platform:

  1. Baris 5-7 (System.getProperty(...)): membaca property yang dilaporkan JVM. java.version menunjukkan versi JDK, java.vm.name menunjukkan implementasi mesin virtual (HotSpot untuk keluarga OpenJDK), dan java.vendor menunjukkan distribusi yang membangunnya — pada lingkungan Course ini, Eclipse Adoptium (Temurin).
  2. Baris 10-11 (String.class.getModule().getName()): menanyakan modul tempat class String tinggal. Hasilnya java.base — modul inti yang selalu hadir, bukti bahwa pustaka standar tersusun sebagai modul, bukan satu berkas raksasa seperti era rt.jar.
  3. 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 berkas
java
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());
    }
}