Wildfly 8, Enterprise Software and the future of Java

On December 21st, 2013, the candidate release 1 of the WildFly (formerly known as JBoss) Java application server version 8 has been made available. Is this the game changer many have been waiting for in the software industry?

Developing professional software applications for enterprises is no small task. Discussing which programming language is the ‘most elegant’ or whether it will crunch a couple more bytes than competition are petty issues. 

One is dealing with multiple teams having multiple responsibilities: design, implementation, maintenance and sales. The implementation process is often spread over many projects and over many years.

Java Enterprise Edition has always been considered by many as an option since its inception. However, software engineers have complained a lot about its complexity and the excessive need for boiler code to get things started. The release of Java EE 5 in May 2006 was supposed to simplify the task, but it did not convince them. It was trying to accomplish too much and to remain too open to all possibilities, rather than delivering productivity.

On October 2006, Spring released its own Java EE framework, though it was not following the Java EE specifications. It was a response to Jakarta Struts, the Apache Foundation implementation of J2EE, whose implementation was considered poor by the Open Source community. Spring remained the preferred framework to develop large software applications, until Java EE 7 was released in July 2013. Today Spring and Java EE 7 are fighting a neck and neck race for the lead.

Issues & Trends

During the 2006-2013 gap, many technologies have risen. For example, Javascript allowed part of the code to be executed on the client side, giving the possibility to reduce the burden on the server side. It has had a tremendous impact on software architecture and user experience. New software implementation tools such as Maven facilitated the implementation of large software applications through modularization. Code repositories, such as Git, also simplified the work across teams, through synchronization.

Yet, the Java EE learning curve has remained very steep in a market where the supply of competent developers was far below demand. The lack of documentation and operational code examples increased the price of Java developers significantly, which weakened the return on investment for Java EE projects. Product maintenance also suffered a lot from this lack of workforce. Stackoverflow, a free website where technical questions can be asked and answers be given by any expert, was a blessing when it became public in 2008. It brought a lot of relief by mitigating the knowledge and expertise issue, but it did not solve it fully. Java EE remained hard and long to learn.

Several engineers turned away from Java for other programming languages such Scala, Python and even Erlang. Node JS, a framework allowing running Javascript on the server side became very popular. These were simply easier to learn and to use, except for Erlang. Although these alternatives were each solving some of Java’s pains, none has actually proved to be a good substitute for large professional software application implementation. Some were lacking a proper editor, some were not doing well regarding performance, some were not scaling well, some were just missing key features.

Another technological hassle to solve was communication between Java EE applications deployed over multiple servers. Those who were using remote method invocation RMI were de facto creating a heavy dependency between applications. If an application was been modified, it often meant that other applications calling it via RMI had to be recompiled too. Fortunately, REST, a set of design principles, and JSON put an end to this issue.

So far, all of the Java EE frameworks have been closely tied to the application server running them via configuration files, especially regarding security implementation and testing. Unfortunately, it is not convenient for software engineers to need an application server for testing during development. The situation has dramatically improved with the recent releases of Java EE 7 and Spring 4.0.

Most software engineers are not system administrators too. They do not like having to configure servers to run their applications. This is why platform as a service (PaaS) has become so successful. It can also facilitate the deployment of scalable applications. Paas is also an opportunity for companies to outsource their hardware and to focus on their core business.

A Game Changer?

So, what are the main issues remaining today? The lack of a system-administration-free platform allowing for the scaling of Java EE applications and proper documentation, mostly. The latter has a key impact on training competent Java engineers. Thus, it has the potential to reduce the gap between offer and demand, and to improve the ROI of Java EE projects.

Regarding documentation, I have been through the Java EE 7 tutorial and can confirm it is a significant improvement over previous versions. The procedure to run examples on Glassfish, via the Netbeans editor, for example, are clear, and the examples do work. I have not been through the Spring 4.0 documentation, but the documentation of late 3.x releases were also a real improvement over previous releases, though small unclear issues remained here and there. So far, Java EE 7 has the best documentation, which eases the learning curve significantly.

As of today, only the Glassfish 3 Application Server is running Java EE 7. WildFly 8 is the next application server on the list. Spring applications can pretty much run on any Java application server. Regarding PaaS, Cloudbees is supporting the implementation of Java EE 7 applications on the cloud via Glassfish 3. WildFly 8 release candidate 1 is available on Openshift. Both Cloudbees and Openshift allow for scalability.

Software developers are also sensitive to the attitude of software companies toward Open Source. There is also some commercial interest at stake, since Open Source is free. Some vendors try to lock-in customers to their products, to secure extra revenues. Both WildFly and Openshift are build by Red Hat, a company which has a strong reputation in the Open Source community. However, Glassfish is implemented by Oracle, which has a bad reputation in the Open Source community.

All in all, WildFly 8, in combination with OpenShift, beats the competition on key business and technical differentiators. In my opinion, it has the potential to be the game changer many developers have been waiting since 2006, regarding large scale Java software implementation.
Jérôme Verstrynge is a software engineer, but also holds an MBA in marketing. He maintains a blog about efficiency too.