A Reason to Hate Enterprise Java

Today, while going through my morning ritual of scanning my RSS feeds, I came across this little gem.These are the kinds of pictures that a software architect or Java evangelist might get giddy over.  Now imagine a development team that needs to, e.g., expose an API as a RESTful service, or create a web site for end users to view their account, or perhaps act as “glue” between two in-house business systems.  To an upper-level manager, such as a VP of Software Engineering, a picture like this would tell me:

• This is powerful stuff, and it will support all of my current and future needs.
• I probably need to pay an outside firm or consultant to explain all of this to my team.

This is undoubtedly the goal of the document.  After all, it’s the upper-level managers who get to make the final call on which technology to use.  However, as a software developer, I don’t want or need an entire “ecosystem” to support my little RESTful service or client self-service web application.  I want the best tool for the job, and that might be a far simpler, lightweight, specialized solution.

Granted, my ideal small solution is somewhere in this mess (sort of - this thing doesn’t even get into frameworks).  My small application probably involves dragging a bunch of other components along to make it all work; a web site won’t work without JSP, which needs a Servlet Container, which probably accesses a database and needs JPA.  Why should I need to care?

I guess my little rant is about a difference in perceived needs.  In my world, many development shops are in need of small, isolated web applications and/or web services that access a database.  There’s a form of security around it, but it’s basically all about getting and/or updating data from a database somewhere, either as a pretty web site or in some data stream (XML, JSON, CSV, whatever) to be picked up by another service and consumed.  Java wants to be all things to all people, from end-user applications on mobile devices to enterprise service busses to web pages and web services.  I’m finding that Java’s myriad “solutions” are less and less relevant to me.

The only thing that binds these disparate products together is the language itself.  Java-the-language is okay, I guess, but it’s not a compelling enough reason to choose this “Technology Concept Map.”  Conceptually, a mobile application is a very different thing than a web application.  Knowing the language doesn’t make my skills transferable if my company decides to get out of the RESTful financial services business, and start making dating applications for mobile phones.  So if my VP of Software Engineering is choosing Java based on the probability that it will meet all of our future needs, then she or he is choosing it for the wrong reasons.

I know that I’m showing up late to the Java-bashing fest, and I’m far from the first person to raise these gripes.  I’m firmly invested, professionally, in Java technology now - I have no intentions of abandoning it any time soon.  But I’m really looking forward to learning some alternatives for building web services and applications.

From http://mikedesjardins.us/