[Preview] Beyond the Limits of Servlets: Unlocking Next-Gen Microservices with Netty and Virtual Threads in Aspectran 9.7.0

Aspectran recently achieved #1 among Java web frameworks in the global Web Frameworks Benchmark, proving its industry-leading throughput, efficiency, and architectural resilience to engineers worldwide.

Yet Aspectran’s journey of innovation never stands still. The upcoming Aspectran 9.7.0 release is far more than an incremental version bump—it marks a fundamental paradigm shift in Aspectran’s web runtime architecture.

Ahead of the official 9.7.0 release, we want to share the architectural philosophy, motivation, and exciting breakthroughs behind this milestone.

1. The Twilight of the Servlet Ecosystem and Modern Backend Challenges

For nearly three decades, Jakarta Servlet (and Java Servlet before it) was the undisputed foundation of Java web development. Deploying WAR packages onto application servers like Tomcat, Jetty, or Undertow, and processing requests through web.xml filters and servlets, reliably served generations of enterprise systems.

However, in today’s cloud-native, containerized (Docker/Kubernetes), and microservice-driven landscape, the traditional servlet ecosystem has increasingly become an architectural bottleneck:

• Heavyweight WAS Overhead: Modern container runtimes prioritize rapid cold-start times and minimal memory footprints. Traditional servlet containers—with their intricate classloader hierarchies, specification compliance overhead, and heavy lifecycle management—inevitably slow down container orchestration and scale-out.
• The Shift to Headless Architectures: Historically, servers rendered HTML views using JSP or template engines (SSR). Today, frontend applications are decoupled into standalone client frameworks like React, Vue, or Next.js, leaving backend services to focus purely on JSON REST APIs and real-time WebSocket data. The vast machinery of servlet specifications designed for page rendering has become redundant overhead for API-first backends.
• Stagnation in the Servlet Specification: Beyond the namespace transition from javax to jakarta, the core servlet specification has seen little fundamental evolution since the non-blocking I/O of Servlet 3.1. Surrounding utility libraries (such as commons-fileupload, commons-io, and custom JSP tag libraries) have remained largely static for years, receiving only occasional maintenance fixes rather than modern architectural enhancements.

2. The Promise of Reactive Streams and the Disillusionment of Reality

As the traditional ‘thread-per-request’ blocking model reached its scalability limits under massive concurrency, the Java ecosystem spent the past decade pursuing Reactive Programming (Reactive Streams), popularized by frameworks like Spring WebFlux.

The promise of handling tens of thousands of concurrent connections with just a handful of threads was immensely compelling. Yet when deployed into production enterprise environments, the hidden costs proved severe:

• Collapse of Readability and Productivity (Mono/Flux Hell): Intuitive, linear business logic written sequentially from top to bottom was replaced by convoluted functional operator pipelines (flatMap, zip, switchIfEmpty). Modifying even simple business logic became an overwhelming cognitive challenge.
• Severance from Proven Enterprise Standards: Because threads switch unpredictably during request execution, the bedrock of Java enterprise architectures—ThreadLocal-based transaction management and security context propagation—was crippled. Teams were forced to abandon battle-tested JDBC, MyBatis, and JPA ecosystems in favor of immature, unstable R2DBC drivers that frequently led to operational issues.
• A Debugging and Troubleshooting Nightmare: When exceptions occurred, stack traces were dominated by dozens of lines of internal framework scheduler mechanics rather than recognizable application code, turning production incident response into a grueling ordeal.

Consequently, many organizations that invested heavily in reactive migrations ultimately concluded that the code was unmaintainable and retreated back to synchronous servlet models.

This raised an essential question: “Must we really sacrifice code clarity, developer productivity, and proven tooling just to achieve high concurrency and performance?”

3. Aspectran 9.7.0’s Solution: aspectran-with-netty

Aspectran 9.7.0 provides a clear, decisive, and elegant answer to this dilemma: aspectran-with-netty—a pure, non-blocking, servlet-less microservice runtime module.

By integrating Netty—the world’s most battle-tested asynchronous networking framework—directly as an embedded native server engine, Aspectran delivers:

• Servlet-less Non-Blocking Networking: Operating without Tomcat or servlet container layers, Netty’s lightning-fast I/O event loops accept and process incoming client network sockets directly.
• Zero-Dependency Native Multipart Processing: The legacy, servlet-dependent commons-fileupload library has been completely eliminated. In its place, Aspectran provides NettyMultipartFormDataParser, powered by Netty’s native HttpPostRequestDecoder and direct memory buffers (ByteBuf) to handle large file uploads at maximum speed with zero external library overhead.
• High-Performance Zero-Copy Static Resource Serving: The built-in NettyResourceHandler provides OS kernel-level zero-copy file transfer (FileRegion), chunked transfers, If-Modified-Since cache validation, and directory index resolution.
• Native WebSocket (JSR-356) Support: Standard WebSocket endpoints run seamlessly on top of Netty without requiring a servlet container.

4. Fulfilling ‘Post-Reactive’: Combining Netty with Java 21 Virtual Threads

How do developers write business logic in this new runtime? Are they forced into complex asynchronous reactive code? Not at all.

Aspectran 9.7.0 couples Netty’s non-blocking I/O event loops with Java 21 Virtual Threads (Project Loom) to realize the definitive ‘Post-Reactive’ architecture:

[Tens of thousands of client requests]
       ↓
[Netty I/O EventLoop]        ← Accepts network sockets using few OS threads (Non-blocking I/O)
       ↓ (Virtual Thread Dispatch)
[Java 21 Virtual Thread]     ← 1 virtual thread per request (near-zero memory overhead)
       ↓
[Aspectran Translet]         ← Business logic executed in intuitive, sequential code!
       ↓ (During blocking I/O, e.g. DB query)
[Carrier Thread Yielded]     ← Instantly yields OS carrier thread to prevent thread starvation

• Network I/O Layer: Netty accepts and multiplexes large-scale connections with minimal OS threads.
• Business Execution Layer: Java 21 Virtual Threads execute incoming requests. Developers write clean, intuitive, synchronous sequential code (Translets, Actions, Beans) without wrestling with Mono or Flux.
• Full Enterprise Ecosystem Compatibility: Battle-tested technologies such as MyBatis, JPA, JDBC, and ThreadLocal-based declarative transactions function seamlessly without modification.

Whenever blocking I/O occurs (such as database access or external API calls), the virtual thread unmounts from its carrier thread, allowing that OS thread to serve other requests immediately. Thread starvation is eliminated at the architectural root.

“Deliver the clearest, most productive development experience to engineers, while providing uncompromising, extreme performance to infrastructure.” This is the essence of Aspectran 9.7.0.

5. An Innovation Absent from Other Netty Frameworks: True Multi-Context Support

Modern Netty-based frameworks such as Spring WebFlux, Quarkus, and Micronaut are almost universally bound to a “1 Process (Container) = 1 Application Context” model. While they permit URL routing prefixes (/api, /admin), this is merely string-based path matching; all beans, security policies, sessions, and configurations remain blended inside a single, shared context.

In the classic servlet WAS era (Tomcat, Jetty), hosting multiple distinct web applications (/, /admin, /api) on a single port with isolated classloaders, session managers, and configuration boundaries was a standard capability. Moving to Netty-based architectures caused modern frameworks to lose this modular separation, forcing teams to allocate separate ports or spin up entirely separate container processes just to isolate an admin interface.

Aspectran with Netty overcomes this limitation by uniting the isolation strengths of servlets with the high performance of Netty.

On a single Netty server port (e.g., 8080):

• Complete DI Container & Rule Isolation: Contexts such as / (root), /admin (management), and /api (public API) each maintain an independent ActivityContext (Bean Registry, Aspects, Translet Rules). Beans and configuration settings in /admin never collide with those in /api.
• Complete Session Isolation (NettySessionManager): Each context manages its own session cookie path and session store. User sessions and administrator sessions are isolated in memory and persistence, ensuring high security boundaries.
• Dedicated Static Resource & WebSocket Bindings: Contexts can individually configure distinct NettyResourceHandler instances (file directories, index files) and WebSocket endpoints.
• Independent Lifecycle Management: Sub-contexts can be dynamically started, stopped, or reloaded without interrupting the primary Netty server.

Operating multiple distinct enterprise sub-applications within a single, ultra-fast Netty runtime without wasting ports or processes is a distinctive architectural advantage exclusive to Aspectran.

6. Elegant Web Module Modularization

To align with this vision, Aspectran 9.7.0 comprehensively refactors its web module architecture:

• aspectran-web (Pure Web Abstraction Layer):
  • Streamlined into a pure web abstraction layer free from third-party servlet dependencies.
  • Legacy dependencies such as commons-fileupload and commons-io have been eliminated, achieving extreme runtime lightness.
• aspectran-web-servlet (Jakarta Servlet & JSP Runtime):
  • Dedicated to traditional WAS deployments, JSP rendering, and servlet filter/listener integration.
  • Serves as an isolated home for servlet-based multipart parsers and custom JSP tag libraries.

Crucially, whether developers deploy to a servlet-based environment (aspectran-with-undertow, aspectran-with-jetty, aspectran-web-servlet) or a servlet-less Netty environment (aspectran-with-netty), the exact same Aspectran configurations (XML, APON, Java Config) and Translet business rules run without altering a single line of code.

7. Epilogue: The Most Pragmatic is the Most Revolutionary

Aspectran does not chase fleeting trends. We listen closely to the challenges faced by engineers maintaining real-world enterprise backends and seek the most pragmatic, reliable architectural path forward.

By honoring and preserving proven foundations (Servlets and JSP) while boldly delivering the cloud-native standards of tomorrow (Netty and Virtual Threads), Aspectran continues its mission to empower developers.

We invite you to look forward to the upcoming official release of Aspectran 9.7.0. Thank you!