# Jooby: modular Java and Kotlin web applications with a choice of servers

> Jooby is a modular web framework for Java and Kotlin that supports script-based and annotation-based application styles across Netty, Jetty, and Undertow. Its documentation covers several extension points, but the README does not provide dependency or installation steps for starting a new project.

**jooby-project/jooby** — The modular web framework for Java and Kotlin

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

## Jooby's modular answer for JVM web applications

Jooby targets developers building JVM web applications in Java or Kotlin. Its central design choice is modularity: the repository contains a core framework under `jooby/` and separate integrations under `modules/`, rather than presenting database access, security, documentation, and other concerns as mandatory parts of one application. The README says this extends to more than 50 thin modules for areas such as Hibernate, JDBI, Flyway, and Pac4j.

This structure addresses a concrete problem in server-side Java development. Teams often have to select a framework, a runtime server, an integration layer for persistence or authentication, and a documentation format. Jooby places those choices around a shared web API. The exact dependency graph is not included in the README, so the claim that every module can be combined freely should not be treated as a compatibility guarantee.

The audience includes developers who prefer Java's explicit APIs, Kotlin users who want a native-facing DSL, and teams working with asynchronous calls through Kotlin Coroutines, RxJava, Reactor, or CompletableFuture. Jooby also presents itself as a microservice framework, although the README does not describe a deployment topology or provide a production configuration tutorial.

## Server selection and Jooby's request-routing architecture

Jooby can run on Netty, Jetty, or Undertow. That choice is separate from the style used to define routes. The Script API is described as fluent and lambda based, while the MVC API uses annotations for applications that fit a more conventional enterprise structure. A team can therefore make two decisions early: which server the application should run on and whether route definitions read more clearly as a small script or as annotated Java or Kotlin components.

The quickest documented examples do not expose a server object, handler chain, or lifecycle callback. They pass an application configuration function to `runApp`, register `GET /`, and return a string from the handler. That is enough to show the public entry point, but not the internal request pipeline. Based on the repository layout, server and integration implementations live in separate Maven modules, while the central framework lives in the `jooby/` directory. The README does not document the exact routing or I/O internals, so a detailed architectural claim would be speculative.

The README also states that Jooby supports reactive and non-blocking programming patterns and names Coroutines, RxJava, Reactor, and CompletableFuture. It does not show a complete streaming endpoint or explain backpressure behavior. That distinction matters. The documented feature set identifies integration options, while the absence of an example leaves execution details for the versioned documentation.

## Jooby installation and first Java route

The README points to Maven Central for `io.jooby:jooby` and links to `https://jooby.io`, but it does not give a dependency snippet, Maven or Gradle setup, or a runnable project command. This repository is a source tree with `pom.xml`, not a published starter repository. Because the README does not specify the required Jooby version, server module, build plugin, or Java compiler settings, inventing an install command would be misleading.

The first documented Java application uses `runApp` and registers a handler for `/`. This is the complete example:

```java
import static io.jooby.Jooby.runApp;

public class App {

  public static void main(final String[] args) {
    runApp(args, app -> {
      app.get("/", ctx -> "Welcome to Jooby!");
    });
  }

}
```

On startup, the configuration callback registers a GET route whose handler returns `Welcome to Jooby!`. The README does not state which port is selected when no server configuration is supplied, so it does not establish what a reader should see in the server console. It also does not include the enclosing `pom.xml`, meaning the example alone is not a complete build recipe.

For a working first use, the missing piece is dependency and engine configuration. Those values must come from the Jooby documentation for the selected release rather than from inference. The repository's own `Dockerfile` is intended for running the test build in a Maven-based container, not for starting the example application.

## Jooby Kotlin DSL and first-class framework positioning

Jooby also documents a Kotlin entry point. The example uses `runApp(args)` and defines `GET /` inside the application block, returning the same welcome string. Its syntax is close to the Java example in what it registers, but the Kotlin form avoids the explicit `app.get(...)` receiver:

```kotlin
import io.jooby.runApp

fun main(args: Array<String>) {
  runApp(args) {
    get ("/") {
      "Welcome to Jooby!"
    }
  }

}
```

The spacing in `get ("/")` is reproduced from the README. It should not be interpreted as a separate DSL method. The handler returns the response text directly, while `runApp` receives the process arguments and the application configuration block.

Jooby describes Kotlin support as first class and also identifies Kotlin Coroutines as a supported asynchronous style. The README does not show a coroutine route, serialization configuration, Gradle build, or Kotlin version matrix. As a result, the snippet confirms the basic Kotlin API but does not establish how a full Kotlin service handles dependencies, routing composition, tests, or deployment. Those checks remain version-specific and belong in the selected documentation set.

## Jooby modules, MVC, OpenAPI, and hot reload

The modular API is most relevant when an application has more than a single route. Jooby names database integrations including Hibernate, JDBI, and Flyway, and security integration through Pac4j. It also states that built-in OpenAPI 3 support can generate interactive API documentation. These are concrete extension areas, but the README does not show their configuration keys, dependencies, generated paths, or authentication behavior.

The Script API and MVC API are alternatives in application organization, not simply different syntax for one example. The script form suits compact applications where handlers are defined beside startup configuration. The MVC API is aimed at annotation-based projects. The README does not explain whether both styles can coexist in one application, how controllers are discovered, or how exceptions and validation are handled, so those compatibility boundaries should be checked before designing around both styles.

Jooby also advertises instant hot reload, meaning code changes can be applied without restarting the entire JVM. That improves the edit loop, but it is separate from production deployment and does not remove the need to build and package the application. The repository contains a `Dockerfile`, `BUILDING.md`, tests, and Maven configuration, indicating a substantial multi-module build. Neither the README nor the Dockerfile documents a container deployment command for a user application. Hot reload should therefore be evaluated as a development capability, not as evidence of a complete production workflow.

## Jooby maintenance, releases, and upgrade boundaries

The repository is not archived, and its last push was on 2026-10-16. That supports the limited statement that source changes were pushed close to the current release activity, but it does not prove the responsiveness of any particular module or issue.

The release list contains `v3.12.0` dated 2026-08-07, `v4.5.4` dated 2026-07-29, and `v3.11.10` dated 2026-07-29. The simultaneous presence of v3 and v4 is a significant upgrade signal. It means an adopter should identify the intended major line rather than copying a dependency or example without checking its version. The README links separate documentation and source branches for v1, v2, and v3, while the current default branch is `main`. It does not provide a migration guide for v4.

Jooby is licensed under Apache-2.0, and the repository includes a `LICENSE` file plus a license file under `etc/source/`. The license permits broad use subject to its terms, but this review does not interpret legal obligations. Upgrade cost cannot be calculated from the repository alone because no dependency count, migration scope, binary compatibility policy, or automated migration tooling is documented. The modular layout may limit what an application needs to adopt, but it also creates version coordination work when multiple modules move between major lines.

## Why Jooby differs from a fixed-stack Java framework

Jooby's clearest alternative is a fixed-stack framework that chooses one server and one application organization model. Jooby instead exposes server choice among Netty, Jetty, and Undertow and route definition through Script or MVC APIs. That difference matters for teams with existing infrastructure constraints. A service already standardized on Jetty can use Jooby without forcing the framework's server selection, according to the README's supported-engine list.

The choice also shifts responsibility to the application team. A fixed stack may reduce server compatibility questions and provide one conventional deployment path. Jooby requires more deliberate selection if an organization needs to align the server, reactive libraries, persistence integrations, security modules, and documentation generation. The benefit is configurability; the cost is more combinations to verify before production use.

Jooby is not the right tool for a team that treats the README as a complete getting-started guide. It also does not fit an evaluation that requires an explicit dependency configuration, default port, Java version, Gradle setup, or production container command to appear in the same place as the first example. The framework may still satisfy those needs in its external documentation. The documented repository simply does not establish them.

## Conclusion

Jooby fits Java or Kotlin teams that want explicit control over the web server and application style, particularly when optional database, security, documentation, or reactive modules matter. It is a weaker choice for developers who need a documented one-command setup from the README or who prefer a single fixed stack. Before adoption, verify the current dependency configuration, module compatibility, server selection, and deployment process in the versioned Jooby documentation, because the README does not supply those details.

## FAQ

### What is Jooby used for?

Jooby is a modular web framework for building Java and Kotlin web applications. It supports Script and MVC APIs, Netty, Jetty, and Undertow, along with modules for areas such as database access, security, and OpenAPI.

### How do I install Jooby?

The README links to Maven Central for `io.jooby:jooby` and directs readers to `https://jooby.io`. It does not include a dependency configuration or an installation command for a new Java or Kotlin project.

### Which servers and programming models does Jooby support?

The README lists Netty, Jetty, and Undertow as supported servers. It also lists the Script API, the MVC API, and asynchronous work involving Kotlin Coroutines, RxJava, Reactor, and CompletableFuture.

## Sources

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

---

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