lesscode.org


Java Tunnel Vision  

By Alex Bunardzic under Talk on 28. August 2005

I am indebted to Stefan Arentz (RoR Tunnel Vision) for helping me articulate better the issue with the impasse software development community is faced with today. His keen observations, while aimed toward explaining how no trace of crisis in the world of software development (and in particular in the world of Java-based development) is detectable on the radar, actually helped me tremendously in corroborating my initial hypotheses.

Stephan begins his rant by admitting how he couldn’t get a clear indication from my original post on what kind of complexity am I referring to when it comes to developing applications using J2EE platform. And here I admit my mistake, caused by my desire to be brief and to the point. I did use the J2EE moniker, but what I actually meant was ‘J2EE-flavored frameworks’. By that I mean any and all of the official and open source frameworks available on the market today. Frameworks such as JCA, JMS, JSF, Velocity, Expresso, Tapestry, Jetspeed, Hibernate, Spring, the list goes on and on.

Any of the above listed and implied frameworks would do; I’ve given a chance to almost all of them, only to turn away in disgust. There’s gotta be a better way! Come on, we’re battle-scared professionals, admit it, there simply has to be a better way.

Stefan tried to reassure me that Java didn’t sit still during its 10 years tenure here on earth (“Alex, you just have to be open minded and stop thinking that Java has not progressed in the last 10”). Yes, I am painfully aware of the fact that Java has progressed (there are days when, in desperation, I think how I wish it did indeed stand still, instead of turning into this Frankenstein that we have to deal with today). As an early adopter and a veritable Java evangelist, I’ve watched the language of my choice transmogrify from seductive little agile, compact product, into the monstrosity that it is today. Needless to say, I’m not amused.

I did buy into Java 10 years ago, hook line and sinker, because I really believed in the power of developing commercial grade business applications without having to depend on moronic, bloated IDEs and the surrounding environmental support (I’ve managed to successfully desert Microsoft’s ‘DLL Hell’, with all its implied complexities and monstrosities, back in 1996). Nine years ago (heck, even seven or eight years ago), only me and my notepad, armed with a small footprint JVM and JSDK on my laptop could walk into a giant corporation and get things rolling in a matter of hours. I could easily build agile applications in Java, quickly cobble up fully functional prototypes, deliver educational sessions on the fly, convert the crowd and talk them into abandoning C++, COBOL, what have you, and move to the new mistress, Java, all from my lowly little laptop. Not having to rely on any tool, other than a simple text editor, I could do high grade, high output work and get paid handsomely.

Then, one day, ouch! Along came IBM and started pushing this completely idiotic product called Visual Age on unsuspecting Java developers. Oh, how I hated the guts of that product! My company forced me to complete weeks and weeks of advanced Visual Age IBM courses, and that was one of the most painful experiences in my software development career. Right there, I knew they are pushing this ‘giant solution in search of a problem’ on people who really, really don’t need it.

Today, if I want to walk into a corporation and offer my Java skills, I need a fancy, state-of-the-art EDI, such as Eclipse (another incarnation of Visual Age, with a lipstick on it) with countless plug-ins and all the bullshit that I don’t really care for. That situation is actually laughable, if you ask me.

Stefan continues with a reasonable observation: “Interestingly, complexity is not something tied to a specific platform. It happens everywhere with all kinds of code.”

True, very true. Everybody knows that complexity is a fact of life, and thus it is unavoidable.

What I was referring to, however, was unnecessary complexity. And my grievance with Java is that it is, as a language and as a platform, unnecessarily complex today.

Here, however, is where we get to the essence of the problem – Stefan writes: “Yes there are a lot of choices, but we are talking about people here who are smart enough to pick Ruby on Rails, so why can’t those people also do a bit of research in the Java world and pick a good framework there.”

You see, Stefan, this is exactly the name of my pain. ‘Do a bit of research’. I’ve spent exorbitant amounts of time in the past six-seven years doing endless research around Java community, relentlessly chasing the elusive dream of the possibility of developing apps in a simple, straightforward way. I’ve tried all the latest and the greatest Java hype, followed religiously every Javaworld and The Server Side and Artima article, but only to in the end throw my hands up in the air in utter desperation. After all was said and done, at the end of the day, all I have is an enormously bloated, to the point of bursting at the seams, Eclipse platform. I am currently nursing countless frameworks, plug-ins, SOA and EMF bullshit is coming out of my ears. My 60 GB laptop with 1 GB main memory cannot take it any more.

All these wonderful frameworks and plug-ins are supposed to turn me into this Super Developer who can crank up incredibly powerful and complex solutions in a matter of minutes. But guess what – instead of being this mythical uber-developer, I can barely get off the ground under the weight of enormous amount of idiotic infrastructure code.

I feel extremely uncomfortable with this situation. I don’t think we, as a community of Java developers, are standing on the solid, firm ground. I think the ground on which we stand is bound to give in under our feet, sooner or later. This is why I’m trying to defect to the Ruby camp, where life is simpler, the air is fresher, and the movement is truly, not nominally, agile.

So, my bottom line answer to your question above is: if Java were truly capable of offering agility, simplicity and power, then the search for a suitable framework wouldn’t have to turn into a multi-month, open-ended wild geese chase. The agility, simplicity and conciseness would be right there, at our fingertips.

Stefan continues with: “Alex, that you cannot be Agile with Java does not mean that it is not possible at all. Many people are extremely agile with Java development. People even wrote books about it. You obviously don’t know what is going on it that world. Is that why you make a straw man argument?”

I am not disputing that it is possible to be agile with Java. Anything’s possible, given sufficient resources. I’m only complaining that, in order to get to be agile with Java, one is forced to invest inordinate, almost astronomical amounts of effort. And that, not surprisingly, comes with the astronomical price tag.

And that is precisely why I say that business computing is in cahoots today, as every move implies astronomical costs. The businesses simply cannot afford to operate in that fashion, regardless of how much fun the developers may be having in their cubicles.

Towards the end, Stefan throws all caution in the air, not being able to resist bragging a little: “Heh. Dude. Who cares that my EJB3 application needs 12MB of jar files. I can now convert a complete persistence model to working code by just writing plain old java objects and adding an annotation here and there to specify the relationship parameters.”

Stefan is obviously proud of the latest and greatest Java crutch – annotations. I’m not going to rain on anyone’s parade here, so I’ll just leave it at that. But it is a vivid example of what usually tends to go wrong with the Java tunnel vision.

I’ve enjoyed Stefan’s parting words: “I invite you to take a second look at Java. Talk to people. See how they are getting more productive. Look around what is going on. You might discover some Really Good Stuff.”

Thanks for the invitation, Stefan. Java is my bread-and-butter, that’s how I make my living these days, so willy-nilly, I am forced to take a second look at it and to talk to people. They are indeed attempting to get more productive by being forced to constantly toss out some old paradigms that were new six months ago and adopt some shiny new paradigm pushed on them by some group of raving developers (like, the aforementioned annotations), that will become old and rusty six months down the road. Last year it was aspect-oriented bullshit. This year, it is annotations. Next year – anyone’s guess.

Let me tell you – people are getting mighty tired of that particular brand of a rat race.

11 Responses to “Java Tunnel Vision”

  1. Ryan Tomayko:

    A wise man once said, “to provide value on the internet, you must piss someone off.”

    Alex, I can state with confidence that you’re definitely pissing people off with this post but the saying goes in a specific direction: pissing people off is a requirement for providing value but it doesn’t guarantee it :) I’m not saying there’s no value here because there is (I especially liked your last paragraph) but a lot of this high level “Is Java bloated?”, “Is Rails less complex?” stuff has been hashed out (with David Hannson being the primary pisser-offer). I think you’d agree that providing compelling reasons for people to consider LAMP, Rails, etc. primarily by illustrating their strengths rather than by ranting against the competition’s weaknesses would be more effective. This is a pro LAMP/Freedom Language site, not an anti-Java site.

    That being said, I’ve went on a few of these rants myself and they’re seductively enjoyable in a get-this-off-my-chest type way but I don’t think it benefits the community as a whole nearly as much as the individual.

    And don’t read more into this comment than is actually stated. I like your writing and I don’t want to dictate the type of content you post here. Consider this contructive feedback from a fellow member of a wider community.

    comment at 28. August 2005

  2. Alex Schroeder:

    I knew our company was going down the wrong track when we started using a Struts-like framework for a finance website and I discovered to my dismay that to be über-flexible and dynamic the code for a simple currency converter had more layers to it than we had developers in our team. I don’t remember the details, but I think to add a new field to one of the screens we had to modify or at least check a file of JSP, XML, XSL, Session Bean, Entity Bean, deployment descriptors, etc. It was totally inappropriate. I left the project convinced that the way we used Java was designed either by architecture astronauts or designed for teams of several dozens of software engineers. But since all the coding I do for a living happens in teams no larger than a dozen developers including the project manager, I suspect that we’re using the wrong tools.

    comment at 28. August 2005

  3. Stefan Arentz:

    Alex, I found myself in exactly the same position as you are now. Stuck in the downward spiral of ‘Sun Java Technology Complexity’. I’ll explain that in more detail. In the end we just made different choices to deal with Java as a development platform. You seem to have ended up bitter about it while I found a way to deal with those issues and put the fun back in Java programming.

    http://www.sateh.com/blog/2005/08/java_tunnel_vision.php

    comment at 28. August 2005

  4. Withheld to protect the ignorant:

    I came to lesscode after reading some of Ryan’s exceptional articles. Ryan is obviously pro-dynamic language, yet his stuff isn’t nearly as prickly as yours is. Why are you so threatened by Java? You come off as a scared kid who wants revenge or something–it’s creepy.

    comment at 28. August 2005

  5. John:

    The main problem is not so much with the Java language, as such (it has its warts and defects, of course, but so do other languages). Nor is it the J2EE platform with all its TLAs (and XTLAs). The main problem is that somehow, Java developers think that all J2EE apps need the works; and that means EJBs and all. The majority of applications I have seen that use EJBs have no need for remoting objects. Nonetheless, the development team have been seduced by the cry of scalability. Rarely is there a cost benefit analysis to justify the added complexity.

    comment at 28. August 2005

  6. Lorenzo Gatti:

    I don’t think Visual Age for Java did much harm to the Java Platform. It was the first Java development environment I used and all later ones, including Notepad plus a console, have been more effective and efficient; but many of its worst features were an unpleasant implementation of unpleasant standards like early J2EE and many others, like the repository, were idiosyncratic and caused no lasting damage.
    VAJ was a forerunner of the bloated IDEs of today, with the main difference that it had to make up for the modest inherent complexity of Java with a wealth of proprietary IBM solutions to IBM problems (e.g. interfacing with CICS software), while current tools can justify their continued existence and outrageous price with a larger J2EE platform, a lot of web services complications and if necessary with machine-readable UML and the accompanying model driven architecture.

    comment at 29. August 2005

  7. Seth Gordon:

    I think the kinds of problems J2EE (and its successor frameworks) was designed to address are problems that Java is fundamentally unsuited to solve, because of the constraints of its type system.

    comment at 29. August 2005

  8. alexbunardzic:

    Ryan,

    “To provide value on the internet, you must piss someone off.” I laughed so hard when I read this. Where did you get the quote from?

    Yeah, you’re right about the sine qua non — in general, people on the internet are the most piss-offable bunch there is. An insanely easy target, not worthy of anyone’s effort.

    I understand you being irritated with me dragging the conversation down into the mud pit. I have my reasons for doing that; allow me to briefly explain:

    1. Stefan accused me of the RoR tunnel vision; I had to retort and talk a bit more about the Java tunnel vision.

    2. The deeper reason for doing that is that I’m starting to get alarmed by the damage Java tunnel vision is doing to our profession. What I mean by that is that, due to the stubborn (I almost want to use the word ‘dogmatic’) insistence on Java’s infallibility, the mainstream software development community is forcing businesses to reach out for desperate measures. This is also a personal peeve of mine, because we’ve just lost a multi-million dollar project to a company in India. This is due to the exorbitantly expensive price tag, enforced on the project by the idiosyncrasies of the Java EE platform.

    What we have here is something closely resembling a panicky situation, where the business are starting to realize that they simply cannot afford to keep paying millions of dollars for every little thing they need to do. And because they have the blinders on, and believe that the only way to accomplish something in a reasonable fashion is to stick to the Java EE/.NET world, they are now scrambling and are trying two types of desperate measures (desperate times demand desperate measures):

    a) Outsource overseas, where labor is more than twice cheaper
    b) Invest in some code generation tool/process/gimmick

    Both of the above desperate measures hurt our profession in more than one way. By insisting that Java (or its derivate, .NET) is the only sensible way to go, we as the developers community are shooting ourselves in the foot, or cutting the branch on which we all sit.

    We need to be proactive and go out of our way to prove it to the stakeholders that there is a better, more affordable way.

    Otherwise, we’ll continue to face the prospect of working in an ever shrinking idustry. I think that would be a shame for such a nice, dynamic, beautiful type of work.

    comment at 29. August 2005

  9. alexbunardzic:

    Stefan writes:

    You seem to have ended up bitter about it while I found a way to deal with those issues and put the fun back in Java programming.

    This is rather fascinating, Stefan! Thanks so much for taking the trouble to elaborate on this:-)

    However, as I’ve explained elsewhere, my bitterness is not about not having personal fun while doing Java, it is more related to the damage that those heavy artillery platforms are doing to our profession.

    The real question (for me, at least), is: can you see your approach taking root and spilling over into the mainstream Java development? If yes, then I’d be willing to sit up and listen. If ‘not really’, then, much as I admire your ingenuity, I’m afraid I’d still stay wary of the overall damage that the behemoths (i.e. Java and .NET) are going to make as they continue rolling downhill.

    comment at 29. August 2005

  10. Assaph Mehr:

    I’m reminded how complex Java web development is whenever I train my fellow coworkers. After I get through explaining Java, JSP, Struts, Hibernate, Ant, and an IDE, the expression is generally a very nice blank stare followed by a WTF??

    Java, with all its agile libraries, is too complex. The only people Java seems to be drawing to its camps these days are people of India hoping to work in the United States.

    comment at 29. August 2005

  11. alexbunardzic:

    Withheld to protect the ignorant wrote:

    Why are you so threatened by Java?

    The reason I’m threatened by Java lies in the fact that I’ve had a misfortune to be involved in numerous Java projects that bombed. Each successive failure is giving another black eye to our profession. Many of my colleagues report same or similar experiences. Everywhere you turn, Java sems to be the touch of death. Businesses are getting very antsy after spending millions of dollars on failed Java projects. They are now desperately branching out to India, China, etc.; at least the continuation of their failed projects aren’t going to cost them that much over there.

    I don’t think it’s good for us, software developers, to be fostering such downward spiral movement. We need to do some damage control and stop shooting ourselves in the proverbial foot. This is why I appreciate Ryan’s and others’ efforts with the lesscode initiative and movement. Let’s work on salvaging the face of our profession. Let’s work on regaining the trust we once had with the businesses. We can do it, we only need to focus some more.

    You come off as a scared kid who wants revenge or something—it’s creepy.

    The last thing I want is revenge. Revenge against whom? I was the one who worked hard on getting us here. I was the foaming-at-the-mouth Java evangelist and raving lunatic, insisting that every goddamned pattern must find its way into the product design. I’m not looking for a revenge against myself, that’s for sure.

    As for creepy, I agree — it is creepy. I’m fighting for my survival, so it’s not a pretty picture:-)

    comment at 30. August 2005