ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Ruby the Rival
Pages: 1, 2, 3, 4

Robert Cooper: Bringing the Hammer

ONJava blogger Robert Cooper recently reacted to some of the "Java end times" talk with his blog entry "It's the End of the World as We Know It." Cooper is an Atlanta-area J2EE developer working on enterprise integration and web/web services applications, and a proprietor of the informative and amusing screaming-penguin.com site.



1. You've said that "The sad truth that 'Enterprise' Java has missed for so long, is that even in the 'enterprise' only one in 500 applications need 'enterprise' functionality." Why would Java developers adopt more sophisticated frameworks than they really need?

Well, there are a couple of things that go to this. One is "buzzword compliance." You want to use what you are "supposed" to be using. I remember back in '99 doing a couple of big projects using entity beans as our data model, where we promptly found out the performance was so horrible we ended up switching back to a hand-coded DAO layer. However, the EJB 1.1 spec at the time was what we were presented with as being the "solution" from the powers that be.

The failure of EJB through the recent changes to javax.persistence, however, has always been the lack of sliding levels of support. Ideally, the framework should have been structured so that if I just wanted basic, easy ORM-type functionality, I should be able to get there quickly. Only then, if I wanted to get into the seriously complicated stuff, present me with a "deeper" view that has distributed transactions. However, even at that top level, look at how many lines of code you need in the EJB 1.1/1.2 world to 1) get the Home stub from JNDI, 2) do a find by, 3) make a change, and 4) commit a transaction. There is no reason that for the average application the answer to that shouldn't be "two." While newer Java frameworks (read: Spring plus Hibernate) get you to that "two," you have to juggle a whole lot of configuration to get there as well. That, in a lot of ways, muddies up your code. A lot of that goes to my "have a workable default configuration/operation" rant, but that is a different story.

2. You've scoffed at Ruby on Rails as "the deification of the next great thing among the technorati." Do you not buy it, or are you just sick of the hype?

It's not that I really scoff so much. Rails is great in a lot of important ways. In fact, if the Flying Spaghetti Monster™ that PHP is would die and be replaced by Ruby, I think that would be a huge step forward. However, for all Ruby does clean up the mistakes of the past and present a compelling new development model for the quick and dirty, it does lack the "deep bench" of functionality that Java has. You might argue that this is simply a matter of time, and it could be. Mostly, however, any hostility I feed toward Ruby/Rails has to do with the features I have wished Java had for a long time and a simplicity of development that I have wished J2EE had for a long time.

3. So what's keeping you in Java, and what works for you?

Well, in terms of my day-to-day work, there is no invoking PCML/RPG programs on the 400 from Ruby. Also, a lot of those actual "enterprise" features that Java has are important, not the least of which is a unified packaging and deployment framework.

4. You say "However, Java seems to have become an also-ran in every possible category. It is not 'the language of the Web,' nor is it a 'first-class citizen' in the desktop." Should Java abandon some of its ambitions and focus on a smaller set of application spaces? If so, which?

You know, I had a long back and forth on my site with a gentleman about this. He noted Java's success in the J2ME world, the TME/TiVo stuff, the set-top box and perhaps the still-a-dogfight next-gen DVD spec. These are all valid spaces for development, but I think if Java just became this kind of system, it would be a loss.

What irritates me is that in the "applet" space that Java invented, you look at Flash(plus Flex/Laszlo) and it crushes applets in both "cool" (get me to a good user experience quickly) and "powerful" (I get data binding/SOAP/XML-RPC/etc. for free). The fact that the "powerful" side of that isn't in the core JRE immediately kills the usefulness of applets, and if anyone can show me an applet that looks anywhere near as good as the Laszlo Dashboard demo in a similar number of lines of code, I might have a coronary on the spot. "Cool" counts for a lot, too.

5. A lot of what you've criticized is Java's increasing complexity, and multiple competing frameworks. Would we be better off coding JDK 1.2 syntax and writing servlets by hand?

My problem with complexity is that it is rarely managed. If you start to look at Swing, for instance, coming from a VB background, it is horribly imposing. There isn't a "simple" interface that you can then cast to more "advanced" interfaces when you need to do something tricky. That is one part of it. The other part is that while these frameworks all have their places, the JRE itself needs to start absorbing some of them into the core so there is at least a "default" way of doing things. Frankly, the last time that happened with anything useful was the JAX-P stuff. There is also, in my mind, a large swath of stuff that is still missing from the core JRE that needs to be there--how old is Swing now, and there is still nothing that gives you the functionality of the VB5 data-bound table control.

I think the JDK1.5 language enhancements are great, myself. When I talk about "reducing complexity" though, what I really mean is A) giving more standard ways to do something so that I only need an external framework if I really need the feature differentiation, B) design APIs so they are more approachable--seriously, look at the JavaDoc on JavaMail and see how long it takes you to figure out how to send an HTML-formatted email, and C) get more of the "common" functionality into the core runtime and offer a style and performance that is comparable to Flash-based or Avalon/Sparkle of the RIA and desktop spaces, respectively. That is to say, I'm not asking for less, I am asking for more and better. In the same way, I remember fondly moving from the VB/VC++ world to Java and thinking, "Gee, it should have always been this way," several years ago, I can't say I look at anything that has been added to Java (with the exception of the forthcoming JAX-WS API) and had that same thought. Looking at Rails, you get that feeling. Looking at Flex you get that feeling. Looking at Avalon you get that feeling. It isn't that I don't like Ruby, it is that I am frustrated that Java doesn't seem to be keeping up.

Pages: 1, 2, 3, 4

Next Pagearrow