1

I'm a long time ASP.NET developer trying to teach myself java. I've got Jetty downloaded and a basic web app setup. The tutorials in Head First Servlets and JSP tell me to reference the container's servlet-api.jar (or servlet-api-3.0.jar in Jetty's case) file when compiling, which makes sense since I'm extending the servlet classes and all, but doesn't this tie my application to a specific container's servlet implementation? If I compile my app against Jetty, can I still deploy the app under Tomcat or any of the EE servers (glassfish, jboss, etc...)?

Chris
  • 27,596
  • 25
  • 124
  • 225
  • I assume you're extending HttpServlet? There is nothing at all Jetty- specific about this class or the http servlet framework in general; you won't be tied to a specific container implementation. – skiller3 Mar 16 '12 at 19:00
  • So why does each container come with its own servlet implementation. Why isn't the servlet API part of the java core libraries or a stand-alone package somewhere? – Chris Mar 16 '12 at 19:01
  • As far as I know containers DON'T have their own servlet implementations. The Jetty maintainers simply bundled the servlet-api-3.0.jar with the download as a convenience to you and because Jetty (like all containers) needs its classes at runtime. The classes aren't part of core java simply because they cater to a very specialized context (granted there is a lot of production servlet code in the world) – skiller3 Mar 16 '12 at 19:05
  • As long as you don't include it in webapp's `/WEB-INF/lib` ther should be no problem. See also e.g. http://stackoverflow.com/questions/4076601/how-do-i-import-the-javax-servlet-api-in-my-eclipse-project/4076706#4076706 – BalusC Mar 16 '12 at 19:38

2 Answers2

2

No, this shouldn't be a problem because you aren't referencing servlet-specific classes. servlet-api.jar is a well-documented specification in the form of several interfaces and abstract classes.

Every container has to have a copy of this JAR (possibly compiled using different Java version, or compiler) because it implements the specification, but the API itself never changes. However note that you don't really have to reference container-provided JARs. You can safely use maven's version or any other you can find. They are all compatible. Sometimes they are not bundled due to various licensing incompatibilities.

That being said: write once, run everywhere applies here as well.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
1

You aren't coding to the jar, you are coding to a specification which the jar happens to contain. Any server providing a web container will have an implementation of this specification, the jar which it is contained in is totally irrelevant.

As long as you only code to the specification, then you are not bound to any server implementation.

The jars are used at compile and runtime to resolve the necessary class dependencies you have. You can use any jar which provides the necessary API dependencies at compile time, but at runtime you will implicitly be using the implementation provided by the specific server. I say implicitly since you do not have to do any specific configuration for your own webapp to include the standard API or it's implementation, the server will already provide that for you, unlike a standalone app.

Robin
  • 24,062
  • 5
  • 49
  • 58