# Bootique for container-free Java applications

> Bootique is a Java launcher and integration platform for building runnable applications without a JavaEE container. It fits command-line tools, jobs, web applications, REST services, and migration tasks, but its module and dependency-injection model adds structure that small standalone programs may not need.

**bootique/bootique** — Bootique is a minimally opinionated platform for modern runnable Java apps.

- Repository: https://github.com/bootique/bootique
- Website: https://bootique.io
- Stars: 1,427 · Forks: 277
- Language: Java
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/bootique-bootique

## Bootique's container-free Java application model

Bootique addresses Java applications that need a launcher and several cooperating components but do not want a JavaEE container as the execution center. The README describes the project as a "minimally opinionated" Java launcher and integration technology for container-less runnable applications. Its intended outputs include REST services, web applications, jobs, and database migration tasks. Each output can behave like a simple command rather than requiring deployment to a separate application server.

This is aimed at Java developers assembling applications from modules rather than developers who only need another JAR on the classpath. Bootique itself is the core repository, while the wider Bootique team supplies modules for specific application concerns. A team may therefore adopt the core programming model and then add only the integrations it needs. The README lists Jersey and Logback as examples, but it does not claim that either one is mandatory.

The central trade-off is modular startup and dependency injection. Bootique can remove the need for a JavaEE container, but it also introduces a module discovery and integration model. A single-purpose program with no services, jobs, configuration, logging integration, or reusable application modules may gain little from that machinery.

## Auto-loaded modules and Bootique's startup path

A Bootique application starts by passing the process arguments to `Bootique.app(args)`. The documented startup chain then calls `autoLoadModules()` and `exec()`, followed by `exit()`. Based on that sequence, arguments enter the Bootique launcher first, modules are discovered automatically, the application executes, and the launcher exits when execution finishes.

The repository characterizes each application as a collection of modules that interact through dependency injection. The core example does not manually instantiate Jersey, Logback, or any other component. Module discovery handles assembly before `exec()` runs the application. That is the architectural distinction from a plain Java entry point, where application code normally constructs and connects its dependencies itself.

Automatic discovery also reduces the amount of visible wiring in the example. It does not mean that an application has no dependencies. The Maven configuration still declares selected Bootique modules, and those modules must be compatible with the BOM version selected by the project. The README does not document custom module selection in this example, discovery rules, startup failure messages, or a way to disable `autoLoadModules()`, so those behaviors should not be inferred.

## Maven setup for Bootique modules

The README directs readers to the Bootique Getting Started guide for detailed installation and identifies Maven Central through the `io.bootique/bootique` badge. Its concrete quick-start configuration starts with Maven dependency management. The `io.bootique.bom:bootique-bom` BOM is imported so participating Bootique modules can be declared without repeating their individual versions.

Add the following `dependencyManagement` entry to the Maven project. The example uses `4.0-M4`.

```xml
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.bootique.bom</groupId>
            <artifactId>bootique-bom</artifactId>
            <version>4.0-M4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>
```

This block imports the BOM but does not yet add application functionality. A reader should confirm that the chosen BOM version is suitable for the project rather than copying the example without checking the release state.

There is a versioning issue to resolve before using the quick start. The README embeds `4.0-M4`, while the release list includes `4.0-M4`, `4.0-M5`, and `4.0-M6`. The README tells users to consult its `maven-central` badge for the current production version of `bootique-bom` and `UPGRADE.md` when upgrading. The newest milestone is not necessarily the correct production choice for every project.

## Adding Jersey and Logback to the Maven project

After importing the BOM, the README example adds two standard modules: `bootique-jersey` and `bootique-logback`. Their versions are managed through the imported BOM rather than repeated in each dependency declaration.

```xml
<dependencies>
    <dependency>
        <groupId>io.bootique.jersey</groupId>
        <artifactId>bootique-jersey</artifactId>
    </dependency>
    <dependency>
        <groupId>io.bootique.logback</groupId>
        <artifactId>bootique-logback</artifactId>
    </dependency>
</dependencies>
```

Jersey supplies the REST-related module shown by the quick start, while Logback supplies the logging integration. Neither dependency creates a complete application by itself. The Java entry point, application behavior, and any required resources still need to be defined.

The README does not document the exact Maven packaging command, generated artifact name, or command used to launch the finished runnable JAR. It points to the Getting Started guide instead. Inventing a command or artifact filename would go beyond its example, so teams should obtain the full build and launch sequence from that guide.

## A first Bootique main method and launch behavior

The shortest documented application has a conventional Java `main()` entry point. In the `com.foo` package, it sends command-line arguments into `Bootique.app(args)`, asks Bootique to load modules, executes the application, and exits. This code is the first concrete application use described by the README.

```java
package com.foo;

import io.bootique.Bootique;

public class Application {
    public static void main(String[] args) {
        Bootique
            .app(args)
            .autoLoadModules()
            .exec()
            .exit();
    }
}
```

The class can run as a Java application because it contains `main()`. The README does not pair this source with a command for building or starting it, however, so the class alone is not a complete installation or launch tutorial. Its more detailed setup instructions are hosted at the linked Getting Started guide.

The example also does not show a REST resource, servlet, scheduled job, database migration, command name, or application configuration file. Jersey is declared as a dependency, but the code does not define an endpoint. Bootique provides the launcher and integration platform, while application behavior belongs in application code and relevant modules.

## Bootique's trade-offs for Java application teams

Bootique's clearest fit is a container-free application assembled from several Bootique modules. The README explicitly includes REST services, webapps, jobs, and DB migration tasks in that category. Dependency injection allows those modules to interact without placing every construction detail in `main()`, while `autoLoadModules()` keeps the startup entry point compact. This can suit applications intended to run as self-contained commands.

The limitation is that Bootique is a platform choice, not merely a convenience library. Adding it means adopting its BOM, module collection, automatic loading, launcher lifecycle, and Java integration conventions. The README is concise and points to separate documentation for the detailed tutorial. It does not explain how to diagnose discovery conflicts, replace automatic module loading, customize the command lifecycle, or operate mixed Bootique module versions in one application.

It is also the wrong architecture when the requirement is specifically a deployed JavaEE application. The repository repeatedly distinguishes Bootique from that model and says no JavaEE container is required. Removing the container can simplify distribution for a runnable JAR, but teams that require standard container deployment, servlet-container lifecycle management, or container-specific administration are choosing a different model.

## Bootique releases, upgrades, and Apache-2.0 licensing

The repository is not archived, and its last push was on 2026-10-10. The release list shows a sequence of 4.0 milestones: `4.0-M4` on 2026-07-01, `4.0-M5` on 2026-08-10, and `4.0-M6` on 2026-08-31. These releases indicate ongoing 4.0 development, but the README advises checking the current production `bootique-bom` version rather than selecting a milestone solely because it appears in the release list.

Upgrade work is not zero-cost. The repository includes `UPGRADE.md` and `UPGRADE-3.0.md`, and the README specifically directs users to the version-specific upgrade notes. Dependency management through the BOM helps coordinate module versions, but developers still need to check whether application modules, dependency versions, or startup APIs changed between releases.

The stated project license is `Apache-2.0`, and the repository contains `LICENSE` and `NOTICES` files. This identifies the project's licensing model, but it is not a legal evaluation of patent terms, notice handling, dependency licenses, or distribution obligations for a particular product.

## Conclusion

Bootique is appropriate for Java teams that want modular command-style applications, especially REST services, webapps, jobs, and database migration tasks distributed as runnable JARs. It is a poor fit for a small application that needs only a `main()` method and ordinary Maven dependencies, or for developers committed to a JavaEE container model. Before adoption, verify that the required standard modules exist for the application, select a coherent `io.bootique.bom` version, and read `UPGRADE.md` for that version because the README example uses `4.0-M4` while the release list also includes later 4.0 milestones.

## FAQ

### What kinds of applications can Bootique build?

The README lists container-less runnable Java applications, including REST services, webapps, jobs, and database migration tasks. Bootique can package this application style for command-like execution without a JavaEE container.

### How do I start a Bootique Java application?

Pass the command-line arguments to `Bootique.app(args)`, call `autoLoadModules()`, then call `exec()` and `exit()`. The README does not provide a complete packaging or launch command.

### Which Maven dependencies are used in the Bootique quick start?

The example imports `io.bootique.bom:bootique-bom` as a BOM and adds `io.bootique.jersey:bootique-jersey` plus `io.bootique.logback:bootique-logback`. The example uses BOM version `4.0-M4`; the README tells users to check Maven Central and `UPGRADE.md` when choosing or upgrading versions.

## Sources

- [bootique/bootique on GitHub](https://github.com/bootique/bootique)
- [License: Apache-2.0](https://github.com/bootique/bootique/blob/master/LICENSE)
- [Project website](https://bootique.io)
- [README](https://github.com/bootique/bootique/blob/master/README.md)
- [Releases](https://github.com/bootique/bootique/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bootique-bootique