What are "Java EE 7 API Library" and "Java EE Web 7 API Library" and when to use them?

Question

I have a full-fledged Java EE project running on GlassFish 4.1 / Java EE 7 (NetBeans 8.0.2) not using Apache Maven.

Depending upon the project functionality, the CDI dependency has to be added to both the projects/modules namely the EE module and the Web module (and a class library, if any).

I have been confusing for a long time seeing people recommending to add either "Java EE 7 API Library" or "Java EE Web 7 API Library" to the compile-time class-path as a CDI dependency (these libraries are bundled in NetBeans and readily available out of the box, when using NetBeans).

Since these libraries contain a collection of APIs possibly the entire Java EE stack starting from the Servlet API, adding one of these libraries to the compile-time class-path (especially in the EE project) does not make sense, when the CDI functionality is needed in Java EE applications.

Why is it suggested many a times especially in NetBeans projects to add one of these libraries, when only cdi-api.jar as a CDI dependency is sufficient?

_{I do not find a canonical answer on this site nor somewhere else as to which library exactly is to be added in NetBeans projects, when the CDI functionality is required in Java EE applications. Adding only cdi-api.jar goes fine, by the way.}

Decidua

My thoughts are that there is more than one way currently to handle dependencies and injections right now in Enterprise Java. This is why you see these recommendations. – Kettledrum

Answer 1

All of javaee-api, javaee-web-api and cdi-api are just API definitions. They do not contain the functinality, they contain only necessary interfaces instead to make your code compile. The result is that none of javaee-api nor javaee-web-api should be included in your application as they already are included with the application server. The implementation is also provided by the application server, which itself is quite big, sometimes with over 100MB of libraries.

If your application just depends on CDI, you are free to put just cdi-api as a dependency. If you want more from javaee, then it is better to choose one of the profiles (full or web). However, mind that the server always provides at least all API included in web profile, therefore it is worth to consider using it too. Picking dependencies selectively is worth only with application servers, which do not support Java EE completely (e.g. Tom EE). In that case, you sometimes even need to include the implementation with your application or put it inside the server.

Varlet

@Tiny, you are right, tomcat is a servlet container and provides only servlet-api, which is a tiny part of Java EE. Although you may build custom application server on tomcat (by handpicking implementations), what I actually meant was something like TomEE, which supports Java EE 6 Web Profile, but Full profile is supported only partially. There may be other less known app servers with partial support too. I corrected my answer by mentioning TomEE instead. – Varlet

Answer 2

As far as I can tell, the Java EE 7 API Library provides the full spec profile, whereas Java EE Web 7 API Library provides only the web profile API. If you're deploying to something like Tomcat, then you only need the web profile (Jax-RS, JSF, JPA). If you plan on doing more enterprise level stuff with Jax-WS (heavy SOAP-based web services), EJBs, JMS, etc, then use the full spec. Do search for Java EE profiles. Last I checked the spec only defined two: FULL and WEB.

In either case, you should mark those as provided in your pom.

Barbey

Tomcat is not a Java EE web profile container. It's a barebones JSP/Servlet container. Things would seriously fail when you treat Tomcat like a Java EE web profile container. – Apollinaire

Thanks for the clarification. I've never used Tomcat, but I was under the impression that it supported the web profile. – Barbey