-2

I've been learning Tomcat and servlets recently. Now I came to realise that the Oracle API and the Tomcat API are at least somewhat different. I know the Oracle API should be wider, but still even in the limits of Tomcat operation, they seem to have completely different packages, etc.

This may seem silly, but I can't find any answer. Could someone please explain the differences? And in practical terms, if I build a service that runs under Tomcat, will it also run in, say, Glassfish, without any refactoring of imports?

--- EDIT ---

So, apparently I mistook Tomcat API for Servlet API, etc.

enter image description here

The solution is not to look at the Tomcat Javadocs in the shot above, but at Servlet Javadoc, or whatever is in question. The list in the pic can be found at Apache Tomcat 8 Documentation Index, on the left, slightly down.

Thanks, Andreas and EJP.

  • What API are you referring to? The Servlet API is a shared standard, implemented by many webapp servers, incl. Tomcat, Glassfish, WebLogic, ... If you want full Java EE API, use TomEE, not Tomcat, since Tomcat is only a Servlet container, not a full EE container. Don't use the Tomcat API you linked, unless absolute necessary. – Andreas Jul 12 '16 at 04:56
  • Thanks. I know that and it's in my question. I don't need full EE. The thing is the packages and classes look different in both APIs or at least the package structures. I can easily find the servlet package in Oracle, but not in Tomcat, for example. –  Jul 12 '16 at 05:04
  • 1
    Sure you can: [Servlet 3.1 API - Apache Tomcat 8.0.36](http://tomcat.apache.org/tomcat-8.0-doc/servletapi/index.html), and [JSP 2.3 API - Apache Tomcat 8.0.36](http://tomcat.apache.org/tomcat-8.0-doc/jspapi/index.html), etc. See "Reference" section on left at [Apache Tomcat 8 Documentation Index](http://tomcat.apache.org/tomcat-8.0-doc/index.html). – Andreas Jul 12 '16 at 05:10
  • 1
    You don't need to trouble yourself about the Tomcat API. You will never use it. What you need to decide between are the JEE API and the Servlet API which forms a small part of it. – user207421 Jul 12 '16 at 05:11
  • Just what I couldn't find. @Andreas –  Jul 12 '16 at 05:19
  • 2
    @Andreas Small correction: [TomEE](https://tomee.apache.org) is *not* a full Java EE implementation, but rather an implementation of the [Java EE Web Profile](https://java.net/downloads/javaee-spec/WebProfile.pdf) plus a few more goodies. So, more stuff than Tomcat, but much less than full Java EE. Also, TomEE implements the Java EE 6 Web Profile, not 7 (just FYI). – Basil Bourque Jul 12 '16 at 06:04

1 Answers1

1

Java Enterprise Edition

What you call the “Oracle API” is actually the Java Enterprise Edition (Jave EE) specification. I suggest you avoid using your misnomer.

Java EE is a vast collection of dozens of varied technologies layered on top of Java Standard Edition (Java SE). Various implementations of Java EE support different pieces, not necessarily all of them.

Subsets of technologies

The Apache Tomcat project, and similarly the Eclipse Jetty project and others, intentionally implement only these technologies:

These few APIs are just a small, but vital, subset of Java EE.

The Tomcat API you linked is specific to Tomcat’s implementation. Developers would only very rarely go through that API. Instead we stick to the interfaces published in Servlet, JSP, EL, and WebSocket specifications all published as JSRs. Sticking to the specs means your web app can be deployed on other implementations as an alternative to Tomcat should the need ever arise.

diagram showing nested subsets of Java EE, Web Profile, Web containers, and distinct from that is the Tomcat-specific API

Web Profile

The Java EE Web Profile is a specification that includes Servlet and JSP APIs along with several more, but still a subset of all the possible Java EE technologies. Apache TomEE is one implementation of the Web Profile, that starts with Tomcat and adds more libraries. Another example is Glassfish, which is/was available in either a complete Java EE edition or a stripped-down Web Profile edition. See the Question, What is different about the Java EE packages? (SDK/normal vs Web Profile).

“Full” implementations

Some products implement all (or nearly so) of the Java EE specifications.

Sometimes this is described as a "full" implementation. I consider that label misleading as it implies the subset implementations are missing or lacking something needed. Quite the opposite. You should always use the leanest implementation that includes only the parts you need. More heavily laden servers take more memory, start and stop more slowly, and may cost more money. For example, I build and deploy highly interactive desktop-style web apps using only Apache Tomcat 8 with Vaadin 7 on top of Java 8 Standard Edition (SE) on Mac OS X.

Also keep in mind that many of the Java EE technologies can standalone, separate from a full Java EE implementation. So you can start with a leaner implementation and then add the libraries for just the few individual technologies you need. For example, Bean Validation can be used on Tomcat by adding the JAR file of an implementation.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154