Java EE makes best-of-breed software conglomerations a thing of the past
Two personal incidents occurred last week which reminded me a little bit about a comment Adam Bien had made to me at JavaOne about choosing the right technology, be it a vendor stack of a best-of-breed software conglomeration, for a given project.
The first incident was a request from my managing editor at TechTarget to do a remediation on the WhatIs.com definition for J2EE. TechTarget is TheServerSide’s parent company, and WhatIs.com is a sister site that lives under the TechTarget umbrella. The extensive dictionary of WhatIs definitions is a great traffic generator for TechTarget sites, but if they aren’t regularly updated, they become stale and out of date. The J2EE definition clearly fits into that category. If you happen to check out the existing J2EE definition, bear in mind that it has been completely re-written and will be updated in its entirety before the end of next month, including an update to the new name: Java Platform, Enterprise Edition (Java EE).
Looking back on the history of Java EE
Updating the definition, which required revisiting the history of the spec, reminded me how much the Java ecosystem has changed and evolved over the years. From the big pivot away from the original EJB specification, to the nuanced changes that occurred after the release of Java EE 5. It’s amazing to see the upcoming specification’s inclusion of cloud support, assistance in creating both SOAP and REST based web services, incorporating batch processing to help with big data applications and the inclusion of JCache to help standardize an important, yet often poorly performed, performance oriented task.
The updating of the Java EE definition came on the heels of an evening out with a software development friend of mine who spent a good deal of the evening complaining about the mind-numbing assignment he’d taken on in which most of his day is spent troubleshooting an application that uses iBATIS to connect to the back-end, takes advantage of Spring to perform dependency injection and is deployed to a WebSphere application server creating a mixture of WebSphere specific features and standard Java EE development, all while the front end is written using Wicket and JQuery.
Abandoning best-of-breed software conglomerations
I know exactly what the architects of that application were thinking when they threw all of those different ingredients into the mix. They wanted a project that leveraged all of the best-of-breed software development frameworks that were available on the market. That’s a noble objective, but the reality behind combining best-of-breed solutions is that interactions between them can get messy, problems can become difficult to troubleshoot and over the long term, it can be difficult to find software developers who are capable of maintaining the solution.
It reminded me of a little Adam Bien sound-byte we recorded at JavaOne. “The truth is, nobody cares about best of breed. Not in my projects, anyways. If it works, it’s good enough,” said Bien, adding in that “Java EE is the best choice because it’s so simple.” Bien is correct, for the vast majority of cases, Java EE is good enough, and there is little need to either layer other frameworks on top of it, or prune some frameworks out of it while plugging others in.
It’s a testament to just how far Java and Java EE has come in the past ten years. I don’t look down on the developers who put together that Frankenstein-esque conglomeration of software development frameworks that included Spring, Wicket, iBatis and a bunch of other libraries. At the time when that application was developed, enterprise Java simply wasn’t as mature as it is now. It’s impressive just how much Java EE has matured over the years. Best of breed implementations really aren’t needed anymore. Java EE works, and for most people, that’s good enough.
You can follow Cameron McKenzie on Twitter: @cameronmcnz.
You can follow Adam too: @adambien
Tweet this article!http://ctt.ec/8NW4J