Saturday, March 19, 2005

Why Java Won't Get It Right

When I was reading DHH’spost about Rife I knew it would stir up the Javaites. And, sure enough, the first few posts were by Java trolls, lashing out and showing their ignorance.

I’ve been developing web applications for about ten years. At least four of those years have been exclusively committed to Java work. Java isn’t bad, but it isn’t great. The Sun marketing machine has made a good group of zombies, I will give it that. You’ve heard the expression ‘drinking the kool-aid’, right? You generally see it referring to pro-Microsoft people. Well the Java group are just as bad, it’s just a different flavor of kool-aid.

Now, I have a very good understanding of Java. I know that it’s not, never has been, and never will be a ‘silver bullet’. Nor has it lived up to the claim of ‘write once run anywhere’. And really, it’s no more ‘scalable’ than any other language.

I love that term; ‘scalable’. Certain people seem to think that by using Java, or .Net, or pick-your-technology, that it’s instantly ‘scalable’. Scalability is as scalability does… OK, that was a little too cheesy, but you get the point, right? It’s not the technology, but what you do with the technology that determines whether it’s ‘scalable’.

Technically speaking, everything is ‘scalable’. The question is: “Does your application code scale well when the user load is increased?”. That question is technology agnostic. The same question applies for RoR.

But I think ‘scalability’ is a red herring. You can create an application in RoR that’s as scalable as one written in Java, or .NET, or whatever technology. However, how productively can you create that application? There are people who think that LOC (Lines Of Code) are irrelevant. And, in a way, I agree. When using an IDE like IDEA, or Eclipse, you can create Java code very quickly. To me, it’s about the number of support, or boiler-plate, classes that have to be written. It’s about how much configuration is needed before you can actually use it.

But I digress. I could spend time ripping Java apart and pointing out it’s inadequacies… But that’s not the point. Every language has inadequacies. Every. Single. One. Ruby included. Java is as viable a language as Ruby, or C#, or hell, even C++. They all have their strengths, and weaknesses.

The main reason I don’t think Java will ever really have a good equivalent of RoR is because of the Java developers themselves. Before you read on, understand that these are generalizations. And no generalizations are accurate on the individual level. But, they can be indicative of behavioral patterns of a group. In others words, what I’m about to say may not apply to you—but seems to apply well to the Java community as a whole.

First, they don’t take the time to truly understands Rails. They say they do, but when you look at the ‘framework(s)’ they’ve written, it’s clearly missing the point of it all. Yes, you can do a scaffold knock-off in Java. You know what? I don’t use scaffolds at all. They are a nice add-on to Rails that can allow the developer to focus on the core of the application. Which is usually a lot more than just CRUD screens.

Second, they can’t reign themselves in. They over-architect everything. I’ve actually used a Java framework (I’m not gonna say which) that had XML config files that configured more XML config files! That’s just silly.

Huh. Well, I didn’t mean for this to become a Java bashing post. Because I like Java. I think it’s a good platform—specifically for web development. I’ve enjoyed using it over the years. It’s just a different mindset than the Rails community. And really, that’s why I think there will never be a ‘Java on Rails’. There is a fundamental difference in what each camp thinks, nay believes, is the right way of doing things.

I really meant for this to be a “why can’t we all just get along?” post. Oh well.

Update: Wow, that thread is getting pathetic. From both sides. Jeez, it’s breaking down into a contest of who has the bigger, er, framework.

4 comments:

  1. Very good post M@. As a Java developer learning RoR and Ruby itself, I must agree, the Java community are a over-architecting group. (Hell, I'm one of them sometimes). Overall RoR solves most problems, but certainly has a long way to go (as I keep finding little issues when I use it) The Java guys just keep making those config files larger and larger, which is annoying as hell. Although there is a push amongst the Spring team to develop a Configuration reader that doesn't use XML and it much more terse.

    ReplyDelete
  2. Thanks. I've been waiting for the hate-comments... Fortunately I fly under the radar of most Java people. ;-)
    Yeah, I used 'they' a lot in this post, but I have to watch over-architecting stuff myself -- it's just so tempting!
    I'm curious to see what the Spring guys have in mind, I've always thought they got things right, in a Java way.

    ReplyDelete
  3. Why Java Won’t Get It Right
    M@ McCray � Blog Archive � Why Java Won’t Get It Right is an interesting entry about some of the problems with Java technology. The best part is that it is written by someone who actually knows Java. A part that I particularly liked was:
    ...

    ReplyDelete
  4. Matt, I'm the first one to agree that there are too many convoluted Java frameworks, which is one of the reasons I started RIFE 4 years ago. You shouldn't look at all XML as evil though, there are situations where it is useful and we use it to declare aspects of the application that don't belong inside the implementation or that cross boundaries. XML is just one possible language for it and when relying on a builder pattern, you can use virtually any language for this, even Java : http://rifers.org/wiki/display/RIFE/Site+structure+and+element+declaration+without+XML
    The thing is that there's also something like under-architecting. Abstracting everything out is indeed over the top, but some things are not trivial and require quite some design. Amongst those are the maintenance of the data flow across the http barrier, the removal of sessions and trying to make things as REST as possible, creating an application that doesn't rely on specific URLs and makes them changeable in one location without having to shift through all code (for several customers we even have to localize them), handling authentication timeouts gracefully without losing data, shifting the logic around when you have to use frames by still being able to concentrate on your main content pane, how to handle wizards and temporary states easily, how to build truly reusable component libraries that you can plugin and share across customers without including source, how to handle portlet-like thingies just like anything else ... etc etc
    We solve these things and many more in this 'XML configuration' which is mostly a site structure with the declaration of everything that flows through the application. We think it's a small price to pay for the benefits you get.

    ReplyDelete