Or is it? Did I get your attention? Well, all of this talk about simplification has gotten mine, especially since it's been going on for years regarding Enterprise Java. For instance, Java EE has introduced features such as annotations and dependency injection to help with complex tasks such as transactions and database connectivity. However, in some ways, I feel this misses the mark; all it does is reduce the amount of code you need to write. This is fine, but it's like telling a musician that you're going to simplify his life by reducing the time he needs to play his instrument. That may not be what the musician had in mind.

Instead, the musician wants to spend more time playing, and less time with other chores (i.e. booking practice time, studio time, mixing, and so on). It's just an analogy, but it does prove a point. I've often felt that Java EE and it associated application servers require me to do more mundane tasks that get in the way of coding. Things like installation, configuration, integration with IDEs, moving tons of files around, starting and stopping servers and services, and so on. What we need is to spend less time on these tasks (and thinking about them), and more time coding.

Frameworks such as Spring try to address the complexities of Java EE, and in many ways it's successful. However, in some ways it too is complex in its configuration requirements. This is probably why so many people stick with Servlets and JSPs, and the frameworks around them that amount to JAR files that simply need to be imported (i.e. Tomcat and Struts).

Java EE 7

The next version of Java EE 7 is focused on further simplification with improvements to the Java Persistence API (JPA) and JAX-RS for REST-based web services. JPA, for instance, contains features and proposed improvements to make it easier to use outside of the Java EE container, and to work with a plug-in model. The goal is to allow vendors to provide a module that simply plugs into your application server or framework and just works. The fact that it requires fewer medial chores, such as writing dumb deployment descriptors, is a boon also.

REST in general, and JAX-RS in particular, are based on paradigms that have become popular because writing full on web services can often be a chore alone. Writing services that support SOAP, WSDL, and other WS-* specs may be appropriate in some cases, but in most cases we just want to make some XML available to callers through a simple set of methods. The methods themselves can often be expressed through HTTP's GET and POST commands, abstracted through a URL query or form post. JAX-RS (and frameworks such as Jersey) make it easier to get your REST services up and running, as well as your client applications that use them.

Third-party Frameworks

In many ways, most of the complexity involved with Enterprise Java development will continue to be addressed by third-parties through both commercial and open-source offerings. Companies like Spring Source, Apache, Terracotta, Electric Cloud, and others will continue to provide solutions to make it easier to build our services and applications, and private clouds. However, another approach comes from companies like Amazon, CA, Google, and others that provide pre-configured and administered hosting platforms for our applications, services, and public cloud infrastructure. These help to reduce or eliminate the time spent deploying and dynamically reconfiguring your apps and services.

To read more about Java EE 7, see http://blogs.oracle.com/java/2011/01/first_jsrs_proposed_for_java_ee_7.html