So GlassFish vs Tomcat, which one is it? First, what if we told you that approximately 63.9% of Java application server installations is Tomcat?
Before you give us a speech on how Tomcat is not an application server but Servlet container. Yes we know, we’re using the term “application server” here interchangeably.
So which is it – GlassFish vs Tomcat?
GlassFish originally released by Sun Microsystems in 2005 is a reference implementation of Java Enterprise Edition (EE). It is currently managed and maintained by Oracle. According to Plumbr.io research, GlassFish powers about 5.6% of all application server deployments.
FYI: in Java a reference implementation is standard (or specification) that demonstrate the concepts. It’s this specification that all further implementations and corresponding customizations are based on.
GlassFish is the Open Source reference implementation for a Java EE application server. In addition to being an open source reference implementation of Java EE application server; GlassFish comes packed with core Java EE technologies such as: Servlets, Enterprise Java Beans (EJBs), Java Persistence API (JPA), JavaServer Faces (JSF), Java Message Service (JMS) as well as the default Java EE SDK.
Furthermore, in addition to being a Java EE application server, GlassFish handles EJB requests thus is also an EJB Container. Also, essentially it has its own web container (a derivative of Tomcat) and thus shares the same Catalina servlet container with Tomcat.
GlassFish vs Tomcat – Apache Tomcat?
On the the hand, Tomcat is a web container (a.k.a servlet container) and HTTP server. As a servlet container, it’s a component of the web server that interacts with Java Servlets and implements the Servlets and JSP specification.
Likewise it’s open source and maintained by the Apache Software Foundation. It is supported by the Apache community and does not have any commercial support. It uses the Apache license whereas Glassfish is licensed under CDDL and GPL.
Tomcat is very popular among developers as well as organizations for simple applications compared to GlassFish. It literally powers 63.8% of Java related web application deployments according to the same Plumbr.io report mentioned above.
Given that it has fewer moving parts unlike GlassFish, Tomcat is much easier to manage and administer. Traditionally, it’s viewed as a “lite” version of Java EE since that it serves as a web server and a Servlet container. Unlike “heavyweight” Java EE application servers like GlassFish or JBoss.
Nevertheless, a lot of deveopers gravitate towards it over the likes of GlassFish because of its simplicity of operation, ease of maintenance, rapid startup and deployment and minimal over-head.
However, bear in the mind it can’t handle EJB components like GlassFish does. However, if you’re building a web application with Servlets and JSP; you may want to use Tomcat because using GlassFish may be an over-kill.
Another aspect in GlassFish vs Tomcat comparison is that Tomcat has a lighter memory footprint. Basically, you’re looking at around a 60MB to 70MB memory footprint whereas Java EE servers like GlassFish need hundreds of megabytes in memory just to get started.
GlassFish vs Tomcat – Quick Round-Up?
Be that as it may, both servers are popular with Integrated Development Environments (IDEs) such as Eclipse and NetBeans. This alone eases deployment, testing and change management that may occur during development.
Subsequently, both are supported and compatible with build tools such Maven and Ant. This ensures easy deployment via continuous integration service such as Jenkins.
As mentioned before, they are both open source and free but with different licenses. Tomcat has a single license whereas GlassFish has dual license.
Finally, they are reference implementations for various Java standards. Tomcat being the reference implementation for the Servlet and JSP specification. While Glassfish is the reference implementation of the Java EE standard (which includes Servlet and JSP).
In conclusion, there is very little you can do with GlassFish that you can’t do with Tomcat.