TornadoVM 7.3.1: SDK GPU untuk JDK 21 sampai 27

TornadoVM 7.3.1 dirilis pada 15 Oktober 2026 dan membawa 28 berkas unduhan resmi di halaman rilis proyek. Menurut catatan rilis di repositori resminya, versi ini menyediakan SDK untuk JDK 21, 25, 26, dan 27, dengan pilihan backend OpenCL, CUDA, Metal, atau paket lengkap, sehingga kode Java bisa dijalankan di GPU tanpa porting manual ke bahasa lain.

TL;DR

• TornadoVM 7.3.1 keluar 15 Oktober 2026 dengan 28 aset unduhan di halaman rilis.
• SDK tersedia untuk JDK 21, 25, 26, dan 27, masing-masing dipasangkan ke backend OpenCL, CUDA, Metal, atau paket lengkap.
• Paket tornado-mlx dan tornado-nccl kini dikirim ke Maven Central lewat pipeline rilis.
• Arsip rilis disediakan untuk Linux amd64, macOS aarch64, dan Windows amd64.
• JAVA_HOME wajib menunjuk JDK yang cocok dengan arsip yang diunduh, kalau tidak, SDK tidak akan jalan.

Apa itu TornadoVM dan untuk apa dipakai?

TornadoVM adalah runtime yang memungkinkan aplikasi Java menjalankan beban komputasi di akselerator seperti GPU, dengan perkakas baris perintah bernama tornado untuk memeriksa perangkat dan versi. Fokusnya bukan menulis kernel baru dari nol, melainkan memindahkan bagian kode Java yang berat ke backend paralel yang tersedia di mesin Anda.

Yang membedakan pendekatan ini dari sekadar memanggil pustaka native adalah status implementasinya sebagai proyek terbuka dengan rilis terpola. Halaman rilisnya mencatat sepuluh versi terakhir: 7.3.1, 7.3.0, 7.2.0, 7.1.0, 7.0.1, 7.0.0, 6.1.0, 6.0.0, 5.2.0-jdk25, dan 5.2.0-jdk21. Rantai versi sepanjang itu penting untuk dipakai sebagai sinyal kematangan, bukan sekadar nomor.

Untuk pengguna yang menjalankan layanan Java di server tanpa GPU diskrit, TornadoVM tetap bisa dipakai lewat backend OpenCL, yang jalan di banyak driver GPU terpasang. Kalau pekerjaan Anda menuntut ekosistem NVIDIA, backend CUDA dan paket tornado-nccl yang baru dirilis ke Maven Central menjadi pilihan yang lebih langsung.

JDK versi berapa yang didukung TornadoVM 7.3.1?

Empat jalur JDK: 21, 25, 26, dan 27. Setiap jalur disediakan untuk empat varian backend, yaitu OpenCL, CUDA, Metal, dan paket lengkap, sehingga jumlah kombinasi arsipnya cukup banyak dan Anda perlu memilih dengan teliti sebelum mengunduh.

Catatan rilis menegaskan satu syarat yang sering terlewat: pastikan JAVA_HOME sudah menunjuk instalasi JDK yang cocok sebelum menjalankan SDK. Contoh di dokumentasi memakai jdk21 dengan OpenCL, dan pengguna dipersilakan menukar nama arsipnya menjadi jdk26-cuda atau jdk27-metal sesuai kebutuhan.

Pemilihan backend sebaiknya mengikuti perangkat yang benar-benar ada, bukan preferensi. Backend Metal hanya relevan untuk mesin Apple, sementara CUDA menuntut driver NVIDIA yang sesuai. Kalau tim Anda memakai mesin campuran, memilih arsip lengkap adalah cara paling sederhana untuk menjaga satu versi SDK tetap konsisten di semua lingkungan pengembangan.

Bagaimana cara memasang TornadoVM dari rilis terbaru?

Unduh arsip yang sesuai, ekstrak, arahkan TORNADOVM_HOME ke hasil ekstrak, lalu tambahkan folder bin ke PATH. Setelah itu, dua perintah pemeriksaan dipakai untuk memastikan SDK benar terpasang, yaitu tornado --devices dan tornado --version.

Di Linux dan macOS, alurnya dimulai dengan wget ke berkas rilis, lalu unzip, dan ekspor dua variabel lingkungan. Di Windows 10 ke atas, langkahnya sama tetapi memakai curl dan tar, kemudian menetapkan variabel dengan sintaks set. Perbedaanya hanya di perkakas bawaan masing-masing sistem, bukan di struktur arsipnya.

Perhatikan nama berkasnya karena memuat versi, JDK, dan backend sekaligus. Contoh di dokumentasi rilis adalah tornadovm-7.3.1-jdk21-opencl-linux-amd64.zip untuk Linux, versi macOS dengan akhiran mac-aarch64, dan versi Windows dengan akhiran windows-amd64. Salah menukar akhiran platform adalah penyebab umum kegagalan pertama saat mencoba SDK ini.

Arsip mana yang harus dipilih?

Jawabannya bergantung pada dua hal: JDK yang terpasang dan akselerator yang tersedia. Tabel berikut merangkum cara membaca nama arsip rilis TornadoVM 7.3.1 supaya Anda tidak salah unduh.

Bagian nama	Pilihan yang tersedia	Cara memilih
Versi SDK	7.3.1	Selalu pakai rilis terbaru selama tidak ada alasan khusus menahan versi
Jalur JDK	21, 25, 26, 27	Samakan dengan JAVA_HOME yang akan dipakai menjalankan SDK
Backend	OpenCL, CUDA, Metal, full	Ikuti driver yang ada di mesin, atau pilih full untuk lingkungan campuran
Platform	linux-amd64, mac-aarch64, windows-amd64	Sesuaikan dengan sistem operasi dan arsitektur CPU

Cara membaca tabel di atas sederhana: nama berkas rilis TornadoVM adalah gabungan keempat baris itu. Karena setiap kombinasi disediakan sebagai aset terpisah, jumlah arsip pada satu rilis bisa mencapai puluhan, dan pada 7.3.1 tercatat 28 berkas.

Apa yang baru di TornadoVM 7.3.1 dibanding 7.0.0?

Perubahan yang tercatat resmi di catatan rilis 7.3.1 adalah pengiriman paket tornado-mlx dan tornado-nccl ke Maven Central lewat pipeline rilis. Langkah ini terlihat kecil, tetapi artinya dua modul integrasi itu sekarang bisa diambil lewat jalur distribusi standar Java, bukan hanya sebagai lampiran di halaman rilis.

Di dalam rantai 7.x, nomor versi bergerak dari 7.0.0 ke 7.0.1, lalu 7.1.0, 7.2.0, 7.3.0, dan berakhir di 7.3.1. Pola penomoran itu konsisten dengan gagasan bahwa perbaikan kecil naik di digit terakhir, sementara penambahan kemampuan naik di digit tengah. Untuk tim yang menjaga layanan produksi, itu panduan praktis: naik dari 7.3.0 ke 7.3.1 lebih ringan risikonya dibanding lompat dari 7.0.0 langsung ke 7.3.1.

Satu hal yang perlu disadari, catatan rilis TornadoVM untuk versi ini tidak memuat klaim angka performa. Jadi jika ada tulisan yang menyebut lonjakan kecepatan tertentu pada versi ini tanpa menyertakan benchmark resmi, angka itu tidak berasal dari halaman rilis dan sebaiknya diperlakukan sebagai klaim pihak ketiga.

Kapan sebaiknya memakai TornadoVM, dan kapan tidak?

Pakai TornadoVM kalau beban kerja Anda didominasi perulangan numerik besar, misalnya perkalian matriks, simulasi, atau pemrosesan citra yang bisa diparalelkan, dan kalau tim Anda sudah memegang kode Java yang ingin dipertahankan. Hindari kalau beban kerja Anda justru didominasi panggilan basis data dan operasi masukan keluaran, karena bagian seperti itu tidak mendapat manfaat dari pemindahan ke GPU.

Alasan pemisahan itu penting: keputusan memakai akselerator bukan soal bahasa pemrograman, tetapi soal bentuk pekerjaan. Operasi yang memindahkan data bolak-balik antara memori utama dan memori perangkat akan memakan biaya komunikasi lebih besar daripada waktu hitung yang dihemat. Karena itu, profil dulu, baru pindahkan.

Untuk organisasi, pertimbangan berikutnya adalah dukungan lingkungan. TornadoVM 7.3.1 menuntut JDK yang cocok dan driver akselerator yang terpasang. Kalau Anda mengelola banyak mesin, sebaiknya standarkan satu jalur JDK dan satu backend, misalnya JDK 21 dengan OpenCL, supaya jumlah arsip yang harus dilacak tidak meledak mengikuti jumlah kombinasi.

Terakhir, perlakukan SDK ini seperti komponen lain di jalur rilis: pin versinya, catat arsip mana yang dipakai, dan uji ulang saat naik digit. Karena SDK-nya dibagi per kombinasi JDK dan backend, satu kenaikan versi bisa menuntut unduhan baru untuk setiap kombinasi yang Anda pakai di produksi. Dokumentasi resmi Java untuk urusan JDK ada di openjdk.org, dan daftar rilis TornadoVM bisa diperiksa langsung di repositori resmi proyek.

Apa keterbatasan yang perlu diantisipasi?

Keterbatasan pertama bersifat operasional: satu SDK hanya melayani satu kombinasi JDK dan backend. Kalau di organisasi Anda ada tiga versi JDK dan dua backend yang dipakai, Anda mengelola beberapa arsip sekaligus, dan setiap rilis baru menuntut pengunduhan ulang untuk tiap kombinasi tersebut.

Keterbatasan kedua ada di sisi perangkat. Backend yang dipilih menuntut driver yang benar-benar terpasang di mesin. Memilih arsip CUDA pada mesin tanpa driver NVIDIA yang sesuai hanya akan memindahkan masalah ke tahap menjalankan perintah pemeriksaan perangkat, bukan menyelesaikannya.

Keterbatasan ketiga menyangkut ekspektasi. Catatan rilis resmi TornadoVM 7.3.1 tidak memuat angka benchmark apa pun, sehingga tidak ada dasar untuk menyimpulkan berapa besar percepatan yang bisa Anda dapat. Satu-satunya cara yang jujur adalah mengukur sendiri pada beban kerja Anda, dengan backend dan JDK yang sama seperti lingkungan produksi.

Sebagai catatan penutup, proyek ini dikembangkan secara terbuka dan riwayat versinya panjang, tetapi itu bukan jaminan bahwa setiap beban kerja Java cocok dipindahkan ke akselerator. Penyaringan sederhana tetap berlaku: kalau operasi Anda lebih banyak menunggu basis data atau jaringan, TornadoVM tidak akan mengubah gambaran besarnya.

Satu catatan praktis untuk tim yang memelihara template OBS bersama: simpan nomor versi OBS di dokumentasi internal Anda, bukan hanya daftar plugin. Karena lokasi plugin berubah di 33.0.0 dan lokasi warisan punya batas akhir di 34.0, catatan versi membuat Anda bisa tahu kapan sebuah instalasi perlu disusun ulang tanpa harus mengingat-ingat riwayat rilis.

Kesimpulannya sederhana untuk tim yang memelihara banyak mesin: standarkan satu jalur JDK, satu backend, dan satu versi SDK, lalu rawat catatan singkat tentang arsip yang dipakai tiap mesin. Tanpa catatan itu, biaya administrasi TornadoVM tumbuh lebih cepat daripada manfaat komputasinya.

FAQ

Apakah TornadoVM harus dipakai bareng JDK tertentu?

Ya, setiap arsip SDK dipasangkan ke satu jalur JDK, yaitu 21, 25, 26, atau 27. Catatan rilis menyarankan JAVA_HOME diarahkan ke instalasi JDK yang cocok sebelum SDK dijalankan, karena ketidakcocokan versi adalah penyebab kegagalan yang paling mudah terjadi.

Apakah TornadoVM bisa jalan di Windows?

Bisa. Arsip rilis menyediakan berkas untuk Windows 10 ke atas dengan akhiran windows-amd64, dan contoh pemasangan resminya memakai curl serta tar. Selain Windows, tersedia juga arsip untuk Linux amd64 dan macOS dengan prosesor Apple Silicon.

Di mana tornado-nccl dan tornado-mlx sekarang didistribusikan?

Menurut catatan rilis 7.3.1, keduanya dikirim ke Maven Central melalui pipeline rilis proyek, sehingga bisa diambil lewat jalur distribusi standar Java. Detail teknis rilisnya bisa dibaca di halaman rilis v7.3.1.

Apakah versi ini sudah diuji untuk beban kerja AI?

Liputan industri menyebut TornadoVM 7 sebagai jalur menjalankan beban GPU dari aplikasi Java, misalnya di ulasan InfoQ. Catatan rilis resminya sendiri tidak memuat angka benchmark, jadi klaim performa harus diambil dari pengujian Anda sendiri.