News Stay informed about the latest enterprise technology news and product updates.

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


.@giltene tells @cameronmcnz there's still a role for bare-metal in #Zing's world of JVM performance #cloud #Java #JVM https://goo.gl/x9m36rTweet this article!http://ctt.ec/8NW4J

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

“Java EE is the best choice because it’s so simple.” I'm not even checking it, but this suggests that JSF is not part of EE anymore. Calling JSF simple... I hardly know anyone who got it properly and most of those who did tried anything else instead. Sure, now we don't have to do any frontend in EE anymore, as we have REST+JavaScript (ouch), but anytime I see "EE is simple" I think it's way biased.
Cancel
Talk about a serendipidous posting. I actually have an article in the copy desk at this very moment arguging *against* putting UI frameworks into the Java EE spec. It's not an anti-JSF thing. I think there are other compelling reasons not to include UI frameworks in Java EE, but that fact that JSF is a 'framework' and not an 'API' is one reason. 

Not sure if you were aware, but Java EE 8 will add a new UI framework, Model-View-Controller (JSR-371 I think). Nothing against the MVC UI framework, but putting UI frameworks into Java EE causes too many problems.
Cancel

-ADS BY GOOGLE

SearchCloudApplications

SearchSoftwareQuality

SearchFinancialApplications

SearchSAP

SearchManufacturingERP

Close