Java EE 6 and 7 compatibility for OmniFaces 2.x

arjantijms edited this page Nov 24, 2014 · 2 revisions

Introduction

OmniFaces 2.x states that it is Servlet 3.0 (Java EE 6) compatible, yet the project seems to have a dependency on things from the Java EE 7 API. What's happening here?

Short explanation

OmniFaces 2.x does not adhere to any official Java EE API. For this version we depend on something that's essentially a mix of Java EE 6 and Java EE 7 elements, namely Servlet 3.0 (Java EE 6), CDI 1.1 (Java EE 7), EL 2.2 (Java EE 6) and JSF 2.2 (Java EE 7), with an optional dependency on Bean Validation 1.0 (Java EE 6).

Details

What to depend on exactly is a surprisingly difficult decision, not in the least because of different opinions people have about this. We held a poll on the topic (see http://arjan-tijms.omnifaces.org/2014/04/what-should-be-minimum-dependency.html) and the majority or respondents chose for Java EE 7 dependencies (Servlet 3.1 and CDI 1.1) and the second largest group of respondents even asked for full Java EE 7 as a dependency.

Yet, we didn't went for the thing the majority asked for. The idea was if the majority of people would be okay with Java EE 7, they would also be okay with Java EE 6, which is a step up from Java EE 5 that we officially supported for OmniFaces 1.x.

Secondly, the JSF spec itself didn't set a good example either. JSF 2.2 is part of Java EE 7, but officially only depends on the oldest versions it can still get away with without compromising functionality too much. This thus means it also depends on Servlet 3.0 (Java EE 6) and CDI 1.0 (Java EE 6).

One thing to think about is who we are exactly doing a favor with this mixed Java EE 6/7 combination.

Users of full Java EE 6 implementations get JSF 2.0/2.1 bundled with their server and in practice can not often upgrade to JSF 2.2. Since OmniFaces 2.x does depend on JSF 2.2, those users often need to keep using OmniFaces 1.x.

Users of full Java EE 7 implementations get JSF 2.2 bundled, but also the Java EE 7 versions of Servlet, CDI and BeanValidation. These users would obviously be better off it we supported Java EE 7 versions of these specs.

Users of home build stacks (in practice these seem to be mostly Tomcat users), can rather easily upgrade their dependencies and are most likely already using the latest CDI implementation (1.2, likely) if they are also using the latest JSF version (2.2 thus). However, Tomcat users cannot upgrade their Servlet version from within a war, so Tomcat 7 (Servlet 3.0) users are the ones who may benefit most.

All in all, we realize the mixed Java EE 6/7 dependency set is perhaps not the most logical one. Servlet 3.0 and EL 2.2 benefits Tomcat 7 users, but there's no real reason to stick with BeanValidation 1.0. At the end we had to make a decision though and we just chose to largely follow JSF 2.2.

For OmniFaces 3.x, which will be aligned with JSF 2.3 we hope to make this all more logical. JSF 2.3 will ship with Java EE 8, which itself depends on Java SE 8, and JSF for the first time will also simply depend on Java EE 8 and Java SE 8. Following that, OmniFaces 3.x will then simply also depend on Java EE 8 and Java SE 8.