Tuesday, April 29, 2014

What should be the minimum dependency requirements for the next major OmniFaces version?

For the next major version of OmniFaces (2.x, planned for over a few months) we're currently looking at determining the minimum version of its dependencies. Specifically the minimum Java SE version is tricky to get right.

OmniFaces 1.x currently targets JSF 2.0/2.1 (2009/2010), which depends on Servlet 2.5 (2006) and Java SE 5 (2004).

In practice relatively few people appear to be using Servlet 2.5 so for OmniFaces 1.x we primarily test on Servlet 3.0. Nevertheless, Servlet 2.5 is the official minimum requirement and we sometimes had to go to great lengths to keep OmniFaces 1.x compatible with Servlet 2.5. As for the Java SE 5 requirement, we noted that so few people were still using this (especially among the people who were also using JSF 2.1) that we set Java SE 6 as the minimum. Until so far we never had a complaint about Java SE 6 being the minimum.

For OmniFaces 2.x we'll be targeting JSF 2.2 (2013), which itself has Servlet 3.0 (2009) as the minimum Servlet version and Java SE 6 (2006) as the minimum JDK version.

So this begs the question about which Servlet/Java EE and Java SE version we're going to require as the minimum this time. Lower versions means more people could use the technology, but it also means newer features can't be supported or can't be used by us. The latter isn't directly visible to the end-user, but it often means OmniFaces development is simply slower (we need more code to do something or need to reinvent a wheel ourselves that's already present in a newer JDK or Java EE release).

One possibility is to strictly adhere to what JSF 2.2 is depending on. This thus means Servlet 3.0 and Java SE 6. Specifically Java SE 6 is nasty though. It's 8 years old already, currently EOL even and we'll probably have to keep using this during the entire JSF 2.2 time-frame. When that ends it will be over 11 years old. At OmniFaces and ZEEF (the company we work at) we're big fans of being on top of recent developments, and being forced to work with an 11 years old JDK doesn't exactly fits in with that.

The other possibility is to do things just like we did with OmniFaces 1.x; support the same Servlet version as the JSF version we target, but move up one JDK version. This would thus mean OmniFaces 2.x will require JDK 7 as a minimum.

Yet another possibility would be to be a little more progressive with OmniFaces 2.x; have the technology from Java EE 7 as the minimum requirement (JSF 2.2 is part of Java EE 7 after all). This would mostly boil down to having Servlet 3.1 and CDI 1.1 as dependencies. Taking being progressive even one step further would be to start using JDK 8 as well, but this may be too much for now.

Besides the version numbers, another question that we've been struggling with is whether we should require CDI to be present or not. In OmniFaces 1.x we do use CDI, but mainly because Tomcat doesn't have CDI by default we jump through all kinds of hoops to prevent class not found exceptions; e.g. using reflection or using otherwise needless indirections via interfaces that don't import any CDI types, which are then implemented by classes which do, etc.

As CDI is becoming increasingly more foundational to Java EE and JSF is on the verge of officially deprecating its own managed beans (it's pretty much effectively deprecated in JSF 2.2 already), plus the fact that CDI is pretty easy to add to Tomcat, such a requirement may not be that bad. Nevertheless we're still pretty much undecided about this.

Summing up, should OmniFaces 2.x require as a minimum:

  1. Exactly what JSF 2.2 does: Servlet 3.0 and JDK 6.0
  2. Same pattern as OmniFaces 1.x did: Servlet 3.0 and JDK 7.0
  3. The versions of Java EE 7 of which JSF 2.2 is a part: Servlet 3.1, CDI 1.1 and JDK 7.0
  4. An extra progressive set: Java EE 7 and JDK 8.0

What do you think? If you want you can vote for your favorite option using the poll at the top right corner of this blog.

Arjan Tijms