Introduction
The Jenesis Launcher turns a modular application into a single executable jar - without giving up its
module graph. Run java -jar app.jar and the launcher reconstructs, in process, exactly what
java -p modulepath -cp classpath -m module/main would have done: modular dependencies become real named
modules in a fresh ModuleLayer, non-modular ones become the unnamed module of the same loader.
The problem it solves
The classic "fat jar" (Maven Shade and friends) unpacks every dependency and merges their classes into
one flat jar. That destroys the things Jenesis cares about: module-info.class files collide, META-INF/services
files have to be merged by hand, and there is no module graph left to reconstruct at runtime.
The launcher explodes each dependency into its own subfolder of the outer jar instead of merging -
modulepath/<module>/… and classpath/<dep>/… - so nothing collides. Each dependency keeps its own module
descriptor, service files, and resources, and the module graph is rebuilt from those subfolders at startup.
Because every class is then a direct entry of the outer jar, the launcher reads it on demand with a plain
ZipFile; the dependencies' bytes never sit in the heap or spill to disk.
What's in this section
- Introduction - you are here.
- How it works - module-layer reconstruction, exploded subfolders, and on-demand reads.
- Producing a launcher jar - the build-tool packaging option and the jar layout.
- Running & troubleshooting - start-up, the single-loader model, and common pitfalls.
- Comparison - how it differs from a shaded fat jar, point by point.
- Reference - the manifest entries and the launcher's own configuration.