Java Servlet container

Past, present, and future.

Past

Soon after its first release in 1996, Java started being used to create dynamic web applications, and from the beginning a special Java web server was used.¹

There were already a few web servers available in 1996.³ Some of them already supported dynamic web pages with CGI.² Why did Java need a special web server? What was so special in Java compared to, for example, Perl which was widely used those years?⁴

A CGI script is started for each matching request and terminated after generating a response. When a CGI script is not serving a particular request, it is not consuming any memory (RAM). And Perl is fast to start.

Java, on the other hand, usually runs in a single operating system (OS) process and relies on threads which share the process memory. A Java application first starts the Java Virtual Machine (JVM). Upon the start, JVM initializes its memory structures, an activity which takes some time. A significant portion of the memory has to be allocated upfront. The relatively slow start of JVM made Java unsuitable for CGI.

Could the JVM be run continuously with its memory structures swapped onto the disk by the operating system when not active and swapped back into the memory when needed, allowing web applications to share hardware memory? Java assumes that will never happen. If it does, the application becomes very slow to respond.

So, in the same 1996, Sun Microsystems released Java Web Server. The idea was to start one Java virtual machine and plug different web applications in to run inside it. That project eventually led to the Java Servlet Specification.¹

How do servlets share the servlet container? A servlet is a plugin for the container. A servlet application is packaged into a .war archive, then deployed into the container without restarting the container itself. The container configures its servlets and routes requests to each of them.

The idea was developed further in Enterprise Java Beans application servers, which provided many more services for servlets in addition to managing their lifecycle and routing requests. Still, there have been application servers which are servlet containers mainly, most notably Apache Tomcat.⁵

Present.

A great number of Java web backend applications have been written as servlets. However, not many servlet containers deployed now run more than one application. Moreover, it became common for applications to start an embedded servlet container.

Why is it not so popular for Java applications to be deployed into a shared servlet container, like a standalone Tomcat, anymore?

Get Andrei Litvinov’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Possible reasons are:

• Hardware memory (RAM) became cheaper. On the other hand, new programs are eager to utilize more memory if available.
• Java virtual machine used to have problems managing large amounts of memory because of garbage collection pauses, and running several applications in the same JVM could exacerbate the problem. However, modern Java garbage collectors have improved a lot.
• The rise of OS virtualization and containerization. However, in the Java case, neither virtualization nor containerization by itself solve the problem of a not very active application having its JVM memory always in RAM.
• When several Java applications run inside a single JVM, they share the same memory address space, and it is not easy to securely isolate them. However, that has always been so.
• I suggest the main reason is the rise of public clouds:

• It is possible to share the hardware memory (RAM) between virtual machines without introducing much delay in the application response time now, using hardware and software tricks⁶. Therefore, the memory of an inactive application may not be actually wasted. That is probably worth doing only if there are a lot of virtual machines around, which is the case with public clouds.
• Public clouds do not like long-running VMs for the obvious reason that it gets into the way of routinely relocating the load between hardware servers. Public cloud customers are now ready for their virtual machines to be terminated without a warning⁷. Shared servlet containers do not fit well into the concept of a disposable VM because it is longer to redeploy a shared servlet container into a new VM and then several applications into it than to redeploy those applications independently.

Future

If we do not deploy several Java applications into a shared servlet container, why do we still write them as servlets? I think mostly because we are used to it.

However, there is a tendency out. There already exist Java web servers which can run non-servlet based applications. Spring Boot, the leading Java web framework, has now a WebFlux sub-project which can run such applications using Netty or Undertow. Even though the goal of WebFlux is stated as mainly non-blocking and reactive handling of requests⁸, the move away from the servlet is notable.

References.

[1] Jakarta Servlet history. https://en.wikipedia.org/wiki/Jakarta_Servlet#History

[2] Common Gateway Interface. https://en.wikipedia.org/wiki/Common_Gateway_Interface

[3] Web Server. History. https://en.wikipedia.org/wiki/Web_server#History

[4] Perl and the birth of the dynamic web https://opensource.com/life/16/11/perl-and-birth-dynamic-web

[5] Servlets and Tomcat: 23+ Years and Counting. By Richard Monson-Haefel. January 16, 2020 https://www.tomitribe.com/blog/servlets-and-tomcat-23-years-and-counting/

[6] Sharing Memory Across Virtual Machines — VMware Docs https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-F9111E35-E197-46EC-8350-77827A5A2DEC.html

[7] Twelve Factor Apps. IX. Disposability https://12factor.net/disposability

[8] Why was Spring WebFlux created? https://docs.spring.io/spring-framework/reference/web/webflux/new-framework.html