Frustrating Aspects of Java EE

written Jun 7th, 2014

When using Java EE to create web applications, Java EE can be a powerful but difficult to use platform. I list in this post some of the more frustrating things I have encountered recently while using Java EE. These frustrations aside, I found creating applications with Java EE to be efficient and without major pains especially for large projects where the initial overhead of the complex platform stops becoming a hindrance and starts simplifying difficult problems.

Firstly, I would like to correct my own post title, as it is not entirely correct to call Java EE a web development framework. It is so much more than that. However, this brings us nicely to the first frustrating aspect of Java EE which bewilders newcomers: what exactly is Java EE?

1. What exactly is Java EE

When I visited Wikipedia, I found this description of Java EE:

Java Platform, Enterprise Edition or Java EE is Oracle’s enterprise Java computing platform. The platform provides an API and runtime environment for developing and running enterprise software, including network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network applications. Java EE extends the Java Platform, Standard Edition (Java SE), providing an API for object-relational mapping, distributed and multi-tier architectures, and web services. The platform incorporates a design based largely on modular components running on an application server.

This explanation of Java EE seems like a definition which you might re-read after mastering a topic and chuckle to yourself as you recognize and appreciate each buzz-word. While each buzz-word may be simple to understand on its own, listing so many buzz-words together doesn’t paint a clear picture of Java EE. While a newcomer to Java EE, I found it very difficult to penetrate past the dense layer of jargon words which were ubiquitous. And it seems I wasn’t alone.

2. 100 ways to do the same thing

With flexibility comes choice. When I began using Java EE, I struggled to decide how to tackle problems, even simple problems. When I am solving a problem, I feel comfortable creating a solution which I feel takes into account best practices and the success of other approaches to similar problems. However, with Java EE I would find myself spending 90% of my time researching architectural decisions before beginning to tackle a task. This was due to the overwhelming choice provided by the Java EE landscape. Here are some of the sources of choice:

There are many implementations of Java EE (this choice can be broken down as each layer of the Java EE stack such as JPA and JX-RS can have multiple implementations).
There are many application servers (such as Glassfish, JBoss AS/WildFly, WebSphere, Tomcat/TomEE, WebLogic)
Which layer of the stack to use: should I put the logic in JSF’s managed beans, or EJBs, or plain Java classes (or sometimes even in JSF/JSP files).
Which mentality should I have: as each Java EE version is released, new approaches to old problems are invented and become available alongside the old ones in a quiver of choices. The new approaches hold promises of increased productivity while the old approaches have reliable documentation, are not as affected by bugs and work alongside my existing code. It reality, a mix and match of new and old get used together.
Packaging options: should I have WARs and EJB JARs in an EAR, or just use a lightweight WAR?

Java EE offers immense flexibility, and if you don’t need this flexibility you will probably waste time having to deal with it.

3. Development is slowed by deployment

Unlike frameworks like the Java/Scala Play Framework or Ruby on Rails, Java EE requires compilation, packaging and deployment before changes can be observed live. The largest application I worked on comprised of a number of modular projects with many separate JARs, WARs and EARs. Testing a few changes would require waiting about 20-30 seconds before seeing them live (using at the time powerful hardware). This delay was torturous when testing minor tweaks. There are some tools to lessen this issue; JRebel allows for instantaneous changes, if you can afford it; and Netbeans has some features for live deployment, but it doesn’t solve the whole problem and you then must give up any choice of IDE if you want the problem solved.

4. PermGen error

While not a universal problem, this memory error can be very annoying while developing and testing. When an application is redeployed multiple times, the application server I used, Glassfish, would steadily increase its memory usage. This is due to the classloaders of the previous deployments and their loaded classes not being garbage collected fully. The memory leak would result in Glassfish having a PermGen Error ever 6-8 redeploys, and would require a forced killing and restart. While this issue was annoying, it did become office humor when someone would get ‘PermGenned’.

5. Cryptic stack traces

It often looks like Glassfish uses my application’s exception trace as a channel to carry out a lengthy conversation with some entity called Grizzy or Felix. Somewhere, often not obvious, the reason for the exception might be buried. The error messages received are often very vague and can cover a broad range of possible root causes.

6. JSF abstracts away important technologies

JSF is great for developers to quickly create nicely looking prototype web applications without having to:

Worry about the details of creating a stateful application on-top of HTTP.
Worry about CSS (instead use a component library, such as Primefaces).

However, JSF does this by abstracting away CSS, HTML and many HTTP characteristics. The abstraction is not easy to work with and obstructs the power of the front end web technologies. This abstraction makes it difficult to work alongside designers and front end developers who are not familiar with JSF. A ThoughtWork’s report highlights some of the issues with JSF and suggests avoiding it.

Java EE’s Potential

Java EE embodies a powerful set of technologies but is difficult to use. Java EE abstracts away a phenomenal amount of complexity and creates a structure to encourage flexibility and extensibility. It may be beneficial to use Java EE if a project is expected to be complex and flexibility is needed. In other cases, using a simpler framework such as the Java/Scala Play Framework, will probably be more efficient.