Meet Java-HTTP: The Lightweight Java HTTP Server Powered by Virtual Threads

java-http offers a zero-dependency Java HTTP server leveraging virtual threads for high performance, handling over 120,000 requests per second.

If you’ve ever felt that spinning up a Java web server means dragging in a pile of dependencies or wrestling with containers, java-http is a breath of fresh air. It’s a zero-dependency Java HTTP server that uses virtual threads (Project Loom, Java 21) to deliver serious performance—120,000+ requests per second in synthetic benchmarks—without giving up the simplicity of synchronous code.

What is Java-HTTP?

java-http is a tiny, open-source Java HTTP server library that feels like part of the JDK: no frameworks, no extra jars, no logging mandates. You choose your logger (Log4j, Logback, or even System.out). You write straightforward handlers. You own the startup, shutdown, ports, and config. Think “Node/Flask-style routing in pure Java,” but with virtual threads under the hood.

Keywords: java-http, Java HTTP server, zero-dependency, virtual threads, Java 21, Project Loom

Why was it built?

Many teams default to Apache Tomcat or Netty. They’re powerful—but can be heavy, complex, or slow to adopt web standards you need right now. java-http flips the model: your app is the entry point, and the server is just a fast, minimal building block. That means smaller attack surface, no dependency hell, and fewer surprises in production.

Key benefits (at a glance)

• Zero dependencies: reduce supply-chain risk and jar conflicts
• Virtual threads: write clean, blocking code while the runtime scales the concurrency
• Fast by design: ~120k rps in microbenchmarks; the server won’t be your bottleneck
• Total control: no container rules—just code, config, and your preferred logging
• Production-tested: used in high-traffic apps (e.g., FusionAuth)

Quick start (clean and simple)

Here’s a tiny server that listens on port 4242 and replies with “Hello”:

import io.fusionauth.http.server.HTTPListenerConfiguration;

import io.fusionauth.http.server.HTTPServer;

import io.fusionauth.http.server.HTTPHandler;

public class Example {

public static void main(String[] args) throws Exception {

HTTPHandler handler = (req, res) -> {

res.getHeaders().put("Content-Type", "text/plain");

res.getWriter().print("Hello from java-http!");

};

HTTPServer server = new HTTPServer()

.withHandler(handler)

.withListener(new HTTPListenerConfiguration(4242));

server.start();

System.out.println("Server running on http://localhost:4242");

Runtime.getRuntime().addShutdownHook(new Thread(server::close));

}

}

Add a simple router-style handler

HTTPHandler handler = (req, res) -> {

String path = req.getPath();

switch (path) {

case "/":

res.getWriter().print("Home");

break;

case "/health":

res.getWriter().print("OK");

break;

default:

res.setStatus(404);

res.getWriter().print("Not Found");

}

};

This is synchronous code, easy to read, test, and debug, while virtual threads (Java 21) handle concurrency efficiently.

When to choose java-http vs Tomcat/Netty

• Pick java-http when you want minimal setup, no external deps, fast startup, and you’re building APIs/microservices without Servlet container features
• Pick Tomcat/Netty when you need Servlet APIs, legacy integrations, exotic protocols, or very specific ecosystem plugins

Performance and realism

The 120k rps figure comes from microbenchmarks aimed at the server layer. In real apps, your bottlenecks are usually the database, external APIs, crypto, or I/O. java-http’s goal is to get out of the way so you can focus on those hotspots.

Who should try it?

• Backend engineers who want a fast, small Java HTTP server
• Platform teams aiming to reduce attack surface and dependency risk
• API builders who prefer clean, readable, synchronous Java powered by virtual threads

Bottom line: If you want a modern, zero-dependency Java HTTP server that lets you move fast with maintainable code, give java-http a try—and keep your classpath blissfully small.

Also Read: How to Use the Compound Components Pattern in React: From Prop Soup to Flexible UIs