DEV Community: 三刀

A Lightweight Java AIO Framework for Long-Lived Connections

三刀 — Sun, 09 Aug 2026 02:10:39 +0000

smart-socket: simple API, small core, built for custom protocols and high connection counts.

The problem with “just use Netty”

Netty is the default choice for high-performance networking in Java — and for good reason. It is mature, battle-tested, and has a huge ecosystem.

But it is also heavy.

If you only need:

Long-lived TCP connections
A custom binary or text protocol
A small, understandable networking layer

…you often end up carrying a lot of concepts, classes, and configuration that you never use.

Java’s built-in AIO (NIO.2) looked promising as a simpler alternative. In practice, many teams found it limited under high connection counts: scheduling inefficiencies, higher memory cost per connection, and occasional stability issues under stress.

That gap is where smart-socket sits.

What is smart-socket?

smart-socket is an open-source Java framework that keeps an AIO-style programming model while reimplementing the underlying engine for better efficiency and reliability.

Core ideas:

Only two interfaces to implement: Protocol<T> and MessageProcessor<T>
A very small, readable core (a few thousand lines)
Buffer pooling aimed at large numbers of long-lived connections
Explicit connection lifecycle events
Optional plugins (SSL/TLS, idle detection, metrics, rate limiting, etc.)

It is not trying to replace Netty for every use case.

It is a focused tool when you want less complexity and tighter control over the transport layer.

Minimal API surface

1. Protocol — turn bytes into messages

public interface Protocol<T> {
    T decode(ByteBuffer readBuffer, AioSession session);
}

Return null when the frame is incomplete (half-packet). That is the entire framing contract.

2. MessageProcessor — handle messages and lifecycle

public interface MessageProcessor<T> {
    void process(AioSession session, T msg);

    default void stateEvent(AioSession session, StateMachineEnum event, Throwable t) {
        // NEW_SESSION, SESSION_CLOSED, DECODE_EXCEPTION, ...
    }
}

3. Bootstrap

// Server
AioQuickServer server = new AioQuickServer(8888, new StringProtocol(), new EchoProcessor());
server.start();

// Client
AioQuickClient client = new AioQuickClient("localhost", 8888, new StringProtocol(), processor);
AioSession session = client.start();

Sending data is straightforward:

WriteBuffer wb = session.writeBuffer();
wb.writeInt(body.length);
wb.write(body);
wb.flush();

No channel pipelines, no bootstrap hierarchies, no codec chains required for the basic case.

A complete echo example

Protocol (length-prefixed UTF-8 string):

public class StringProtocol implements Protocol<String> {
    @Override
    public String decode(ByteBuffer buffer, AioSession session) {
        if (buffer.remaining() < Integer.BYTES) {
            return null;
        }
        buffer.mark();
        int length = buffer.getInt();
        if (length > buffer.remaining()) {
            buffer.reset();
            return null;
        }
        byte[] bytes = new byte[length];
        buffer.get(bytes);
        return new String(bytes, StandardCharsets.UTF_8);
    }
}

Processor:

public class EchoProcessor implements MessageProcessor<String> {
    @Override
    public void process(AioSession session, String msg) {
        byte[] body = msg.getBytes(StandardCharsets.UTF_8);
        WriteBuffer wb = session.writeBuffer();
        try {
            wb.writeInt(body.length);
            wb.write(body);
            wb.flush();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Server:

public class EchoServer {
    public static void main(String[] args) throws Exception {
        new AioQuickServer(8888, new StringProtocol(), new EchoProcessor()).start();
    }
}

Maven dependency:

<dependency>
    <groupId>io.github.smartboot.socket</groupId>
    <artifactId>aio-pro</artifactId>
    <version>2.1.3</version>
</dependency>

Design highlights

Enhanced AIO runtime

smart-socket presents an AIO-style API but uses a carefully tuned asynchronous implementation underneath. The goal is better scheduling behavior and lower overhead for typical server workloads with many concurrent connections, while keeping the programming model familiar.

Memory model

A page-based buffer pool (BufferPagePool + VirtualBuffer) reduces allocation pressure and supports sharing pools across servers/clients when needed. This matters when you hold tens or hundreds of thousands of long-lived connections.

Plugin chain

Cross-cutting concerns stay out of your business code:

Plugin	Role
SslPlugin	TLS/SSL
IdleStatePlugin	Idle / heartbeat
MonitorPlugin	Metrics
RateLimiterPlugin	Traffic control
StreamMonitorPlugin	Byte-level monitoring
BufferPageMonitorPlugin	Pool visibility

Extend AbstractMessageProcessor and call addPlugin(...).

Clear state machine

You get explicit callbacks for connection establishment, shutdown, decode/process errors, and accept rejection. That makes it easier to implement reconnect logic, metrics, and graceful close without guessing.

When to choose smart-socket

Good fit

Custom binary or text protocols
IM, IoT gateways, device management, internal RPC
Long-lived TCP connections at scale
Teams that want a small core they can actually read
Resource-constrained or “keep the stack thin” environments

Probably not the best fit

You need a full HTTP/WebSocket stack out of the box
You rely heavily on Netty’s ecosystem of codecs and community handlers
You want an application framework rather than a focused transport library

Ecosystem

smart-socket is used as the networking foundation for several projects:

feat — lightweight high-performance Java web framework
smart-mqtt — MQTT broker aimed at large-scale IoT
Redisun — lightweight Redis client
smart-servlet — Servlet container on the same core

If the framework can power MQTT brokers and web stacks, it is past the “toy project” stage.

Try it

GitHub: https://github.com/smartboot/smart-socket
Docs: https://smartboot.tech/smart-socket
License: Apache 2.0

Feedback, issues, and contributions are welcome — especially from people building real long-connection services.

If you have been looking for something lighter than Netty for custom protocols and persistent connections, smart-socket is worth a weekend experiment.

Why Do Java Frameworks That Challenge Spring Always Lose to "Developer Experience"?

三刀 — Sat, 04 Jul 2026 07:48:36 +0000

GitHub：https://github.com/smartboot/feat

Almost every Java developer has complained about Spring: slow startup, memory-hungry, bloated dependencies. Change one line of code, wait five seconds for a restart, staring at that line in the console — "Started Application in 5.234 seconds" — you can't even tell if it's a log message or a mockery.

What hurts even more is when you complain to a colleague that "Spring is too slow," they'll most likely hit you with: "So you want to use Vert.x? Or Quarkus?"

You go silent. Because you know those frameworks are indeed fast, but you also know — learning new APIs is painful, team training is expensive, and being unable to find answers when things break is desperate. In the end, you sigh and keep waiting for those five seconds. After all, "at least I know how to use it, at least everyone on the team knows how to use it, at least I can Google the answer when something goes wrong."

This kind of "developer endurance" — we've all been through it.

But here's a counterintuitive fact: over the past decade, Vert.x, Quarkus, Micronaut, Solon… countless frameworks have crushed Spring on performance benchmarks, yet not a single one has truly shaken its position.

Why?

Because when it comes to technology selection, the first person to make the call isn't the CTO, not ops — it's the programmer sitting at their desk. And a programmer's top priority when choosing a framework has never been "how much electricity this server will save," but rather "how fast can I learn it, how enjoyable is it to write, and can I find answers on StackOverflow when things break."

Spring's real moat has never been technology — it's the "human" experience.

1. Where Did Spring Win?

Many people think Spring's dominance comes from its massive ecosystem. But the ecosystem is just the result, not the cause.

The real reason is: from day one, Spring's design philosophy was never "high performance" or "lightweight" — it was the ultimate developer experience and productivity.

Think about it — which evolution of Spring ever caused you pain? From Spring to Spring Boot, from Spring Boot to Spring Cloud, developers barely had to relearn anything; it was just a natural extension. Your resume says "proficient in Spring," and at the next company's project, those @Autowired, those @RequestMapping, those debugging strategies — still completely applicable. You don't even need to read the docs; muscle memory lets you complete 80% of the development work.

That's Spring's most terrifying strength — it built a comfort zone of mental models. In this comfort zone, auto-configuration makes you feel "understood" rather than "interrogated"; IDE plugins make you code like a wizard; and those 200,000 Q&As on StackOverflow, the countless tutorials on YouTube, the wall of "Spring in Action" books in the bookstore — together they form a barrier no new framework can overcome.

On a deeper level, Spring has become a team collaboration language. When two Java developers sit down together, they don't need to explain what dependency injection is, what AOP is, what transaction propagation is — these concepts have been internalized as the industry's common language. No matter how good a new framework's performance is, if it can't integrate into this common language, it creates friction costs in team communication.

To put it bluntly, Spring is essentially a "developer welfare framework." It shifts costs from developers to companies' cloud bills. Meanwhile, challengers often shift costs back to developers — you learn new APIs, step into new pitfalls, dig through GitHub Issues for three days to find an answer — all in exchange for performance gains on the machine.

In economic terms, this is a trade destined to fail.

2. The "Fatal Blind Spot" of Performance-First Frameworks

The Java community has never lacked "technology-first" open-source projects. Their selling points are remarkably consistent: fast startup, low memory usage, high QPS.

These are indeed what enterprises need. But the problem is: just because enterprises need it doesn't mean programmers will choose it.

Imagine this scenario: you recommend a new framework to your team, saying "it starts in just 100ms." A colleague asks: "How does it inject dependencies?" You say: "Programmatic configuration." Another asks: "What about database access?" You say: "Write your own Reactive Client." Then: "When something goes wrong in production, can you even understand the stack trace?"

By this point in the conversation, you've already lost.

4 seconds faster startup, but 4 weeks of learning curve; 8MB less memory, but 8 hours debugging a bizarre issue; 9 out of 10 team members know Spring, and hiring someone who knows some niche framework won't even pass resume screening. Not to mention when your boss asks: "Will anyone still maintain this framework in the future?"

Performance advantages show up on machines, while experience disadvantages show up on people. Enterprises pay for machines, but programmers pay for themselves. This is the structural dilemma of all "technology-first" frameworks.

3. Feat's Third Path

While developing Feat, we've been asking ourselves a question: instead of building "a better Vert.x," could we build "a faster Spring"?

The answer is yes. The core idea boils down to one sentence: Write Spring-style code during development, generate efficient plain Java code at compile time.

Specifically, in Feat you still write the familiar @Controller, @Bean, @Autowired, @RequestMapping — the mental model stays exactly the same. But when you run mvn compile, the annotation processor reads these annotations at compile time and generates the corresponding CloudService implementation classes. These generated classes handle bean creation, dependency injection, route registration, and resource cleanup.

At runtime, Feat no longer scans annotations or uses reflection — it directly loads the generated plain Java classes via ServiceLoader and executes them according to a fixed lifecycle. Route calls become ordinary method invocations, dependency injection becomes direct field assignment. No reflection, no dynamic proxies, no full classpath scanning at startup. The annotations you write are merely "intent declarations"; what actually runs is plain Java code generated at compile time.

What does this mean?

We ran a comparison test: the same Hello World example, Spring Boot 4.1.0 takes over five seconds to start with 12MB of memory; Feat needs only 400ms and 4MB of memory.

From five seconds to four hundred milliseconds, from twelve megabytes to four. You're still writing that same return "hello", but the engine behind it has completely changed.

More importantly, configuration errors are caught directly at compile time, instead of throwing an obscure reflection exception at startup or even at runtime. Since everything at runtime is plain Java code, Feat is also naturally friendly to Native Image, with even greater optimization potential in the future.

You don't need to leave your comfort zone — just swap the furniture inside for lighter materials.

4. Honest Boundaries

Of course, Feat is not a clone of Spring, and we have no intention of overstating.

The current data is based on Hello World scenarios; we will continue to publish results under real-world business complexity. Feat makes reasonable simplifications to Spring's fine-grained annotations — the core development model is consistent, but it's not 100% syntax-compatible. Additionally, after modifying Controllers, Beans, or feat.yml, a recompilation is required; during local development, ensure your IDE triggers Maven compilation.

Peripheral ecosystems like Spring Data, Spring Security, and Spring Cloud are still under construction in Feat.

We acknowledge the gaps, but we also want to demonstrate a path: high performance and great developer experience have never been mutually exclusive.

Final Words

The Java community doesn't need a second Spring, but it needs someone to prove: developers don't have to compromise between "the joy of writing code" and "the speed of running code."

Spring defined what Java development "should feel like," and that in itself is a great contribution. What Feat wants to do is make that feeling run a little faster.

Technology selection has never been a purely technical problem — it's a people problem. When a framework makes developers feel "I know how to use it, I dare to use it, I'm willing to use it," it has already won half the battle.

If you're also tired of the endless startup wait, give Feat a chance. After all, those few seconds you save are enough for one more sip of coffee.

What truly holds independent developers back is not their capability, but the frameworks they use.

三刀 — Tue, 23 Jun 2026 07:27:55 +0000

Official Website: https://smartboot.tech/feat/

If you're a solo developer, you probably know this feeling all too well:

You're building a small project. SpringBoot is your go-to — you can get it up and running in no time. But then deployment day comes, and the problems start piling up. A simple admin backend system produces a fat jar that's easily 20MB+, and once it's running, it demands hundreds of MB of memory. You don't dare go too low on your cloud server specs, and the bills just keep stacking up.

For solo developers fighting on their own, these "hidden costs" can be quite painful — the more projects you have, the more your cloud server expenses snowball out of control.

Amid the AI Layoff Wave, OPC Is Becoming a New Path Forward

Lately, "AI layoffs" and "one-person company" have been trending almost simultaneously.

On one side, big tech companies keep swinging the axe: in Q1 2026, global tech layoffs have already approached 80,000, and quite a few companies have been blunt about the reason — AI enables small teams to deliver the same output as large teams; they simply don't need as many people anymore.
On the other side, many of those laid off haven't rushed to squeeze into the next job. Instead, they've leveraged AI to amplify their individual capabilities and pivoted to running OPCs (One-Person Companies).

These two phenomena are actually two sides of the same coin: organizations are cutting headcount while individuals are picking up the slack. If you're considering (or have already been pushed onto) this path, your choice of infrastructure matters far more than it did when you were working at a big company — a one-person company doesn't have an ops team to cushion your server bills and stability concerns. The lighter the framework, the more resource-efficient it is, the more battle-tested and durable it proves to be, the more projects you can juggle simultaneously and the more forgiving your cost of experimentation becomes. This might be exactly why frameworks like Feat — "lightweight yet powerful" — are riding this wave perfectly.

I happen to have a project of my own that recently went through this kind of migration. Here's the process and the data, for your reference.

A Real Migration: Let the Numbers Talk

The project is smart-license, an open-source software licensing management solution. Its admin backend was originally built on SpringBoot.

Gitee Repository: https://gitee.com/smartboot/smart-license

After migrating to Feat, here's how the key metrics changed:

Metric	Before Migration (SpringBoot)	After Migration (Feat)
Fat Jar Size	20MB+	4MB
Memory Usage	Hundreds of MB	170MB
Stable Uptime	—	Over 6 months, zero abnormal restarts

A quick note: the business functionality and number of API endpoints remained essentially equivalent before and after the migration — no features were trimmed in the process. These numbers reflect the inherent differences between the frameworks, not "slimming down by cutting features."

The jar is 5x smaller, memory usage dropped significantly, and this isn't lab data — it's the result of running in production for over six months. For solo developers, this means you can run more projects on the same cloud server configuration, or simply switch to a cheaper machine.

Feat: Lightweight but Not Simple

Feat is a Java-based lightweight, high-performance web server, positioned as "outperforming Vert.x in performance, with a development experience close to SpringBoot."

Four keywords summarize its strengths:

Free — Apache 2.0 open-source license; free for commercial use and unrestricted secondary development
Elastic — Elastic scaling architecture, effortlessly handling hundreds of thousands to millions of QPS
Advanced — Full support for HTTP/1.0–2.0, WebSocket, SSE, TLS, with built-in routing, file uploads, and WAF
Tiny — Microkernel architecture, cold start in under 100ms

Here's what a minimal service looks like:

package com.example;

import tech.smartboot.feat.Feat;

public class HelloWorld {
    public static void main(String[] args) {
        Feat.httpServer()
                .httpHandler(request -> request.getResponse().write("Hello Feat"))
                .listen(8080);
    }
}

Just a few lines of code — no maze of annotations or configuration files to wrestle with. This is precisely the root of its "fast cold start and small package size" — the microkernel architecture doesn't carry a burden of unnecessary dependencies.

Feat Cloud: Written for Those Who Love the SpringBoot Way

Feat Core already covers most lightweight scenarios, but if you've bought into Feat's technical direction and don't want to give up the comfort of SpringBoot's annotation-driven development, Feat Cloud delivers a much closer experience:

@Controller
public class Bootstrap {

    @RequestMapping("/hello")
    public String helloWorld() {
        return "hello Feat Cloud";
    }

    public static void main(String[] args) {
        FeatCloud.cloudServer().listen();
    }
}

@Controller, @RequestMapping — the coding style feels right at home for SpringBoot developers. Beyond that, Feat Cloud also comes with built-in MyBatis integration, session management, MCP services (i.e., AI Agent capabilities), Native Image compilation support, and other advanced features — this part is continuously refined through a sponsorship support model. I'll dive into the details in future articles.

Final Thoughts

As a solo developer, your energy and budget are limited — framework selection actually has a huge impact. Choose something too heavy, and the hidden costs of deployment and operations will slowly erode your time and enthusiasm.

That's all for this post. I'll be writing more about Feat in practice over time (such as how to smoothly migrate from a SpringBoot project, how to package with Native Image). If you have a project you're looking to migrate similarly, or want to learn about Feat Cloud's sponsorship/licensing options, feel free to reach out — I'm happy to offer practical advice based on your specific situation.

Feat - High-Performance Java Web Service Framework

三刀 — Thu, 19 Mar 2026 11:44:51 +0000

Somewhat like Vert.x, and somewhat like Spring Boot, Feat is a Java web service development framework.

🚀 Enterprise Value of Feat

Advantage	Description
⚡ High Performance	Several times faster than traditional frameworks, significantly reducing server costs
⏱️ Low Latency	Millisecond-level response, enhancing user experience
📦 Easy to Use	Simple API design lowers the learning curve
🔐 High Reliability	Stable operation reduces operational pressure

📦 Third-party Package Dependencies

The main third-party package dependencies for each module in the Feat framework are as follows:

Module	Dependency	Type	Description
Feat Core	smart-socket	Runtime	A Java AIO-based network communication framework
Feat Core	fastjson2	Runtime	Alibaba's JSON processing library
Feat Cloud	mybatis	Compile-time	An excellent persistence layer framework
Feat Cloud	snakeyaml	Compile-time	YAML configuration file parsing library
Feat AI	-	-	-

All dependencies use the latest stable versions to ensure optimal security and performance.

Performance Comparison

Compared to other mainstream Java frameworks, Feat excels in the following areas:

Metric	Feat	Spring Boot	Vert.x
Startup Time	<100ms	~700ms	~500ms
Memory Usage	Low	High	Medium
Requests per Second	High	Medium	High
Response Latency	Extremely Low	Medium	Low

Documentation & Community

📚 Learning Resources

Official Documentation: Detailed usage guides and API references
Sample Projects: Practical examples across various scenarios
Performance Test Reports: Understand Feat's performance advantages

💬 Getting Support

GitHub Issues: Report issues or suggest new features
Gitee Issues: Domestic user feedback channel
Enterprise Licensing Solutions: Empowering efficient development and enterprise growth

🤝 Contributing

We welcome contributions in all forms:

Report Issues: Help us identify and fix bugs
Improve Documentation: Make documentation clearer and more complete
Contribute Code: Implement new features or fix known issues
Share Experience: Share your experiences and best practices using Feat within the community

Please read our Contribution Guide before contributing.

License

Feat is open source under the AGPL License.

Feat - A Supersonic Java Framework for the Cloud Native Era

High Performance • Low Resource Consumption • Developer Friendly