Java
  • Java Workshops
    • JEPS
      • JEP 286: Local-Variable Type Inference
      • JEP 404: Generational Shenandoah
      • JEP 450 : Compact Object Headers i
      • JEP 472 : Prepare to Restrict the Use of JNI
      • JEP 475 : Late Barrier Expansion for G1
      • JEP 478 : Key Derivation Function API
      • JEP 479: Remove the Windows 32-bit x86 Port
      • JEP 483: Ahead-of-Time Class Loading & Linking
      • JEP 484: Class-File API
      • JEP 485: Stream Gatherers
      • JEP 486: Permanently Disable the Security Manager
      • JEP 487: Scoped Values (Fourth Preview)
      • JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
      • JEP 489: Vector API (Ninth Incubator)
      • JEP 490: ZGC: Remove the Non-Generational Mode
      • JEP 491: Synchronize Virtual Threads without Pinning
      • JEP 492: Flexible Constructor Bodies (Third Preview)
      • JEP 493: Linking Run-Time Images without JMODs
      • JEP 494: Module Import Declarations (Second Preview)
      • JEP 495: Simple Source Files and Instance Main Methods (Fourth Preview)
      • JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
      • JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
      • JEP 499: Structured Concurrency
      • JEP 501: Deprecate the 32-bit x86 Port for Removal
    • TODO
    • Workshops
      • JDK24 workshop
Powered by GitBook
On this page
  1. Java Workshops
  2. JEPS

JEP 493: Linking Run-Time Images without JMODs

PreviousJEP 492: Flexible Constructor Bodies (Third Preview)NextJEP 494: Module Import Declarations (Second Preview)

Last updated 3 days ago

📌 What Is This JEP About?

JEP 493 simplifies the use of the jlink tool by allowing developers to create custom Java runtime images without needing .jmod files.

💡 Motivation

Before JEP 493, if you wanted to build a custom runtime image using jlink, you had to:

  • Compile your code as a modular JAR

  • Then generate a JMOD file using the jmod tool

  • Only then could you run jlink to create a runtime image

This made the process more complicated and redundant—especially in build pipelines or for library authors.

📦 What is a .jmod File?

A JMOD file is a format introduced with the Java Platform Module System in Java 9. It's:

  • A package format for compiled module artifacts

  • Contains .class files, native libs, configs, etc.

  • Used internally by the JDK for standard modules

Think of it like a fatter version of a JAR—but mostly useful for JDK developers, not application developers.

🛠️ Problem With JMODs

For most real-world modular applications:

  • You already build modular JARs

  • You rarely need native code or special packaging

  • Creating .jmod files adds unnecessary steps

  • Build systems like Maven and Gradle don't produce JMODs by default

This creates friction.

✅ What JEP 493 Changes

JEP 493 allows jlink to:

  • Accept modular JAR files directly

  • Skip the need for .jmod files altogether

  • Treat modular JARs and JMODs interchangeably as input to the module path

So now:

Modular JAR → jlink → Custom Runtime No intermediate .jmod step needed.

🚀 Benefits of JEP 493

Benefit
Explanation

🧹 Simpler Workflows

No need to generate .jmod files manually

⚙️ Tooling Compatibility

Works smoothly with Maven/Gradle outputs (modular JARs)

📦 CI/CD Friendly

Easier automation in pipelines

🧩 Modular Adoption Boost

Lowers the barrier to adopting Java modules

🧪 No Loss of Functionality

Native libraries and launchers still supported in other ways

📜 Summary

  • .jmod files are no longer required to link custom runtimes

  • jlink now accepts modular JARs directly

  • This improves developer experience, simplifies builds, and removes redundancy

  • JEP 493 is a quality-of-life improvement for modular Java projects

LogoJEP 493: Linking Run-Time Images without JMODs