# Minum is a Java web framework built on the standard library alone

> Minum is a server-side-rendered Java web framework with zero dependencies outside the Java 21 SDK, bringing its own HTTP server, routing, templating, in-memory database, logging and test utilities in about 7,000 lines of production code. The trade-off is stated plainly by its author: it is a sharp knife that does not hold your hand, and it follows semantic versioning on a fast 11.x line.

**byronka/minum** — The smallest and simplest Java web app framework

- Repository: https://github.com/byronka/minum
- Stars: 665 · Forks: 49
- Language: Java
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/byronka-minum

## Everything the framework needs comes from the Java 21 SDK

Minum is built with no dependencies other than the Java 21 and later SDK. The documentation names what it deliberately does not use: no Netty, no Jetty, no Tomcat, no Log4j, no Hibernate, no MySql. What sits inside the framework instead is its own web server, endpoint routing, logging, templating engine, HTML parser, assertions framework and database, with the implementation described as ordinary and well-tested code built on hashmaps and sockets. The whole program is a small server-side-rendering web stack. A concrete example from the documentation shows the shape of an application, where the system is initialised, a path is registered for the GET method with a handler that returns an HTML response, and the process is told to block:

```java
public class Main {
    public static void main(String[] args) {
        var minum = FullSystem.initialize();
        var wf = minum.getWebFramework();
        wf.registerPath(GET, "",
                r -> Response.htmlOk("<p>Hi there world!</p>"));
        minum.block();
    }
}
```

There is no deployment descriptor and no layered context object hierarchy to read. The framework follows semantic versioning, and the design process it states is make it work, make it right, make it fast.

## The size comparison is the actual argument

The README puts the case in a table of production lines of code including required dependencies: Minum at 6,919, Javalin at 141,048 and Spring Boot at 1,085,405. It also states a compiled size of 209 kilobytes, and describes minimalist competitors as ranging from 400,000 to 700,000 lines once their dependencies are counted, against 7,000 for Minum. The reasoning behind the number is what matters for a reviewer. A small codebase can be understood, tested and debugged; a large one cannot, and the framework's own claim is that this makes understanding, testing and debugging easier by magnitudes. There is a companion document, docs/size_comparisons.md, with the finer detail, and the point is not that smaller is always better but that the cost of the framework is something a team can actually inspect.

## No reflection, no annotations, no magic

Three prohibitions define the framework's style, and each one is a design decision with a cost. No reflection: the method calls are all scope-respecting, so the code base reads in plain order. No annotations: unlike certain other frameworks, the design principle is to use only ordinary Java method calls for all behaviour, and configuration is minimal and relegated to a properties file, which at the repository root is `minum.config`. No magic: nothing unusual happens behind the scenes and there are no bytecode runtime surprises. This is what makes the codebase plain to read, and it is also why the framework offers fewer of the conveniences that annotations and dynamic proxies normally provide, since wiring is expressed as ordinary code that a reader can follow. The related trade-off appears in the README's own words: it does not hold your hand or provide guardrails, and most frameworks offer faster early stages in exchange for difficulty as the project progresses.

## The web stack includes a server, a database and a queue

The feature list is where the minimalism claim gets tested, and it covers the everyday needs of a web application. There is a secure TLS 1.3 HTTP/1.1 web server. There is an in-memory database with disk persistence, where all data is held in memory and written to disk as well, and the only time data is read from disk is at database startup, an approach the documentation presents with both benefits and risks. There is server-side templating, where a template is a string with replaceable areas such as "Hello {{ name }}" and the processor renders it quickly. There is logging, testing utilities built around confirming expectations, HTML parsing, and a background queue processor that can keep running programs in parallel with the request-driven code that covers most of the codebase. The documentation frames the whole list as the persistent storage and templating any web application would need, without pulling in a framework to do it.

## Adding the dependency and starting from the quick start

The artifact is published to the Maven central repository under the coordinates com.renomad with the artifact name minum:

```xml
<dependency>
    <groupId>com.renomad</groupId>
    <artifactId>minum</artifactId>
    <version>11.0.3</version>
</dependency>
```

For getting started, the documentation points to a quick start guide at docs/quick_start.md, and to a longer tutorial under docs/getting_started/getting_started.md for those with more time. The repository itself is set up for that workflow rather than just for consumption: it ships a Maven wrapper as `mvnw` and `mvnw.cmd`, a `pom.xml`, and a Makefile whose purpose is to wrap the longer Maven invocations in short aliases. The Makefile sets the project name, the version, the Maven wrapper path and the output directory, and its comments explain that aliases like make mutation_test save you from typing the full plugin invocation. Nothing in the repository requires a specific IDE or a global Maven install.

## The testing story is unusually explicit for a framework

Quality claims in a framework README are usually marketing, but this one is checkable in minutes. The documentation states 100% test coverage, branch and statement, running in 30 seconds without any special setup, invoked with `make test_coverage`, and close to 100% mutation test strength using the PiTest mutation testing tool with `make mutation_test`. Mutation testing is the interesting one: it changes your code in small ways and checks that your tests actually fail, so a coverage number on its own tells you little. The Makefile's test target runs the Maven wrapper with the JaCoCo agent and report goal, and there are further targets for cleaning output directories and for the jar, with the file explaining that handling the jar recipe with Make is simpler than a Maven customization. The design is described as test-driven from the outset, and the coverage claim is stated as a result of the minimalism paradigm.

## An 11.x line with a stated downside

The project is MIT licensed, sits on a fast version line and says plainly what it costs you. The release history shows v11.0.1 on 2026-08-06, v11.0.2 on 2026-09-30 and v11.0.3 on 2026-10-03, with the last push to the repository on 2026-10-18, and the repository is not archived. The 11.0.x notes are small and specific, covering documentation improvements and fixes found from analysis. The project also publishes an unusual AI usage statement: large language models were used for static analysis of the code and the bugs found were fixed manually, and the stated principle is that all lines of production code are primarily constructed and reviewed by a human. The same document describes the work as thousands of hours by an experienced practitioner experimenting with maintainability, performance and pragmatic simplicity, which is a fair description of a framework that sets out to be a sharp knife rather than a safety net.

## Conclusion

Small Java services that want server-side rendering, are willing to own the boring parts of HTTP, and value a codebase they can read end to end are the audience for Minum, and the size difference against the usual suspects is large enough to matter for debugging and onboarding. It is the wrong choice for a team that needs batteries included guardrails, a large dependency ecosystem, or mature integrations, and the framework's own documentation says so. Before you commit, read docs/quick_start.md and the tutorial, and try `make test_coverage` in the repository, since the quality claims in the README are claims you can check in a few minutes.

## FAQ

### What does Minum need to run a Java web application?

Only the Java 21 SDK or later, since the framework has no dependencies beyond it and does not use Netty, Jetty, Tomcat, Log4j, Hibernate or MySql. The web server, routing, templating, logging, HTML parsing and database are all part of the framework itself.

### How do I add Minum to a Maven project?

The artifact is published to the Maven central repository, so you declare a dependency on groupId `com.renomad`, artifactId `minum` and the version you want, for example 11.0.3. The documentation also points to a quick start guide and a longer tutorial for the first application.

### How does Minum store data?

Its database keeps all data in memory and writes it to disk as well, and the only time data is read from disk is at database startup. The documentation describes this as an approach with both benefits and risks.

### How do I run the tests and the mutation testing?

The Makefile provides short aliases for the Maven commands, so `make test_coverage` runs the tests with coverage reporting and `make mutation_test` runs the mutation testing with PiTest. The project states 100% branch and statement coverage that runs in about 30 seconds without special setup.

### What are the trade-offs of using Minum?

The documentation is explicit that the framework does not hold your hand or provide guardrails, describing it as a sharp knife if you know how to wield it. The benefits it claims are easier debugging, maintainability and lower overall cost, in exchange for slower early stages than most frameworks.

## Sources

- [byronka/minum on GitHub](https://github.com/byronka/minum)
- [Issues](https://github.com/byronka/minum/issues)
- [License: MIT](https://github.com/byronka/minum/blob/master/LICENSE)
- [README](https://github.com/byronka/minum/blob/master/README.md)
- [Releases](https://github.com/byronka/minum/releases)

---

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