Java sering dicap tua, berat, dan kalah seksi dari bahasa baru. Tapi lucunya, salah satu perubahan paling menarik di dunia runtime justru lagi datang dari Java: Project Valhalla.

Artikel ini membahas kenapa JDK 28 mulai membawa value classes and objects lewat JEP 401, apa maksud “object tanpa identity”, dan kenapa ini penting buat developer backend yang peduli performa. Jawaban singkatnya: Java mau memberi cara buat menulis model data yang tetap terasa seperti class, tapi bisa lebih hemat memory dan lebih ramah buat JVM. Ini belum berarti semua aplikasi Java tiba-tiba jadi secepat C atau Rust, tapi arahnya penting banget.

Apa itu Project Valhalla?

Project Valhalla adalah proyek OpenJDK untuk mengembangkan model object Java supaya bisa menggabungkan dua hal yang selama ini sering terasa bertabrakan: abstraksi object-oriented dan karakteristik performa primitive.

Kalau disederhanakan, Valhalla mengejar ide: codes like a class, works more like a primitive. Lu tetap bisa mendesain data dengan class, method, dan tipe yang jelas, tapi JVM punya ruang lebih besar buat menyimpan data itu secara efisien.

Di halaman resmi Project Valhalla, OpenJDK menjelaskan bahwa fitur ini tidak akan dikirim sekaligus. Ada beberapa bagian besar: value classes and objects, null-restricted storage, array enhancements, penyatuan primitives dan classes, sampai Parametric JVM untuk optimasi generics. Jadi JEP 401 bukan “Valhalla selesai”, melainkan tahap awal yang mulai masuk jalur JDK.

Masalah lama Java: object punya “bagasi” identity

Di Java, object biasa punya identity. Artinya dua object bisa berisi nilai yang sama, tapi tetap dianggap object berbeda karena lokasi/identitasnya beda.

Money a = new Money(10000, "IDR");
Money b = new Money(10000, "IDR");

System.out.println(a == b);      // false untuk object biasa
System.out.println(a.equals(b)); // bisa true kalau equals diimplementasikan

Identity ini berguna untuk banyak hal: mutability, locking, referensi object unik, dan pola OOP klasik. Tapi untuk data yang sifatnya murni nilai, identity kadang jadi bagasi yang tidak perlu.

Contoh gampang: koordinat, money amount, tanggal, complex number, warna RGB, atau pair angka. Kalau dua nilai sama, seringnya lu tidak peduli “ini object yang sama persis atau bukan”. Lu cuma peduli nilainya.

Masalahnya, object Java tradisional tetap membawa konsekuensi object: referensi, header object, potensi alokasi heap, pressure ke garbage collector, dan locality memory yang kurang ideal. Di skala kecil mungkin tidak terasa. Di skala besar, terutama data structure padat atau pipeline yang banyak bikin object kecil, overhead ini bisa jadi biaya nyata.

JEP 401 membawa value object ke Java

JEP 401 berjudul Value Classes and Objects (Preview). Ringkasnya, JEP ini memperkenalkan value objects: instance class dengan field final dan tanpa object identity.

Tujuan resminya cukup jelas:

  • Developer bisa memilih model immutable data yang dibedakan berdasarkan nilai field.
  • Class immutable yang sudah ada bisa bermigrasi secara kompatibel jika cocok.
  • Class di JDK seperti Integer dan LocalDate bisa diarahkan agar punya value object instances.
  • JVM punya kebebasan lebih besar untuk mengoptimalkan footprint memory, locality, dan efisiensi garbage collection.

Bagian pentingnya: ini preview. JEP 401 berstatus submitted dan updated 17 Juni 2026, tetapi bukan fitur production default yang langsung wajib dipakai semua orang. JVM Weekly juga menekankan bahwa integrasi ini menargetkan JDK 28, masih disabled by default, dan baru bagian pertama dari perjalanan Valhalla.

Value object bukan “struct di Java” begitu saja

Ini jebakan framing yang sering muncul. Begitu ada istilah value object, orang langsung menyebutnya “struct di Java”. Analogi itu membantu di awal, tapi bisa menyesatkan kalau terlalu jauh.

JEP 401 sendiri eksplisit menyebut bahwa tujuannya bukan memperkenalkan fitur struct baru di Java. Java tetap berjalan dengan dua jenis data utama: primitive dan object reference. Yang berubah adalah model object tertentu bisa dibuat tanpa identity, sehingga JVM punya peluang optimasi yang sebelumnya lebih terbatas.

Jadi, cara baca yang lebih aman:

  • Value object cocok untuk data immutable yang maknanya ada di nilai, bukan identitas.
  • Value object bukan pengganti semua class.
  • Value object bukan alasan buat memakai == sembarangan di semua tempat.
  • Value object belum berarti layout memory terbaik langsung aktif di semua kondisi.

Menurut gua, poin terakhir ini penting. Developer sering terlalu cepat mengubah fitur preview menjadi janji performa mutlak. Padahal di runtime, detail implementasi, compiler, VM flag, library, dan workload tetap menentukan hasil akhir.

Kenapa developer backend perlu peduli?

Kalau lu menulis Java untuk API biasa, mungkin hari ini belum ada perubahan workflow. Tapi sebagai developer backend, lu tetap perlu paham arah ini karena problem yang disasar Valhalla fundamental banget.

1. Memory bukan detail kecil

Banyak sistem modern bottleneck-nya bukan cuma CPU, tapi memory layout, cache locality, dan jumlah object kecil yang harus diurus garbage collector. Kalau data yang harusnya sederhana justru tersebar sebagai banyak object reference, CPU bisa buang waktu hanya untuk mengejar pointer di memory.

Value object memberi ruang buat JVM menyimpan data immutable dengan cara yang lebih compact dan lebih ramah cache. Ini bukan sihir, tapi jenis optimasi yang masuk akal untuk runtime besar seperti JVM.

2. Immutable data makin penting

Banyak desain modern mendorong immutable object: lebih aman untuk concurrency, lebih mudah dipikirkan, dan lebih enak untuk domain modeling. Tapi immutable object di Java kadang tetap terasa mahal kalau jumlahnya besar.

Valhalla mencoba menutup gap itu: lu bisa menulis tipe data yang ekspresif, tapi tidak selalu membayar overhead object identity yang tidak lu butuhkan.

3. Java masih bergerak di level fondasi

Topik seperti framework baru lebih mudah viral. Tapi perubahan runtime seperti Valhalla bisa punya dampak lebih panjang. Ini mengingatkan gua bahwa platform yang terlihat tua belum tentu berhenti berevolusi.

Bahasa dan runtime yang dipakai jutaan sistem tidak bisa berubah sembarangan. Kadang satu fitur butuh riset bertahun-tahun karena harus kompatibel, aman, dan bisa jalan di ekosistem yang luas. Itu bukan lambat tanpa alasan; itu trade-off platform besar.

Contoh mental model: kapan identity perlu, kapan tidak?

Lu bisa pakai pertanyaan sederhana ini saat mendesain class:

  • Kalau dua instance punya field yang sama, apakah harus tetap dianggap beda?
  • Apakah object ini butuh lifecycle unik?
  • Apakah object ini akan dimutasi setelah dibuat?
  • Apakah object ini dipakai untuk locking atau identity-sensitive operation?
  • Apakah nilainya kecil, banyak, dan sering dibuat ulang?

Kalau jawabannya lebih sering “tidak butuh identity” dan datanya immutable, value object menjadi konsep yang relevan. Kalau object punya lifecycle, state berubah, atau butuh identitas unik, class biasa tetap lebih cocok.

Yang jangan dilakukan: ikut hype tanpa ukur workload

Begitu fitur seperti ini masuk headline, biasanya muncul dua ekstrem. Satu sisi bilang Java akhirnya “mengejar Rust”. Sisi lain bilang fitur ini terlambat dan tidak penting. Dua-duanya terlalu malas.

Menurut gua, cara paling sehat adalah melihat Valhalla sebagai investasi runtime jangka panjang. Bukan alasan buat rewrite aplikasi. Bukan juga fitur yang harus diabaikan karena belum stabil.

Kalau lu kerja di ekosistem Java, yang bisa dilakukan sekarang:

  1. Pahami konsep identity vs value equality.
  2. Biasakan mendesain immutable data dengan jelas.
  3. Ikuti perkembangan JEP 401 tanpa langsung pakai di production.
  4. Uji di workload nyata saat early-access atau preview sudah cukup matang.
  5. Jangan jual klaim performa sebelum ada benchmark sesuai kasus lu.

Takeaway buat developer

  • Project Valhalla bukan fitur kosmetik. Ia menyentuh cara Java memodelkan object dan nilai.
  • Value object cocok untuk immutable data. Terutama data yang maknanya ada di field, bukan identity.
  • JEP 401 masih preview. Jangan diperlakukan sebagai fitur production default.
  • Performa butuh konteks. Memory footprint, locality, dan GC efficiency bisa membaik, tapi tetap perlu diuji.
  • Java belum selesai berevolusi. Platform besar sering bergerak pelan karena harus menjaga kompatibilitas.

FAQ singkat

Apakah Project Valhalla akan membuat Java langsung lebih cepat?

Tidak otomatis. Valhalla memberi fitur dan ruang optimasi baru untuk JVM, terutama untuk data immutable tanpa identity. Dampaknya tergantung cara fitur dipakai, implementasi JVM, dan workload aplikasi.

Apakah value object menggantikan class biasa?

Tidak. Class biasa tetap cocok untuk object yang punya identity, lifecycle, state berubah, atau perilaku yang bergantung pada referensi unik.

Apakah JDK 28 sudah pasti membawa semua fitur Valhalla?

Tidak. Berdasarkan sumber resmi OpenJDK, Valhalla dikirim bertahap. JEP 401 adalah bagian value classes and objects dalam status preview, bukan seluruh roadmap Valhalla.

Penutup

Hal yang gua suka dari Project Valhalla adalah dia tidak terlihat seperti hype cepat. Ini bukan tools baru yang viral seminggu, lalu hilang. Ini perubahan fondasi yang mencoba menjawab problem lama: gimana caranya Java tetap enak dipakai untuk modeling, tapi tidak terlalu mahal untuk data kecil yang jumlahnya banyak.

Kalau lu developer Java, backend engineer, atau cuma tertarik cara runtime bekerja, Valhalla layak dipantau. Bukan karena lu harus pakai besok pagi, tapi karena fitur seperti ini ngajarin satu hal penting: performa software sering dimulai dari cara kita memodelkan data.

Referensi / Bacaan Lanjut

Tags:
#Java#Software Development#JVM#Performance