The JDO 2.0 expert group has released the Early Draft Specification for JDO 2.0. At 272 pages, it’s some nice light reading to start your day off. Still, persistence isn’t a trivial problem, so its not surprising that this spec needs to be large to fully address the problem.

I can’t yet gauge how fully the O-R Mapping portion will address real application needs, but it looks like a good start, the whole thing does, and I think, for once, I’m going to review the spec enough to provide some of that “public feedback” they’re soliciting. Hopefully the EJB3 expert group can give feedback on how JDO 2.0 can be tweaked to meet the needs of Entity Bean persistence instead of continuing this absurd pissing war that the groups have been involved in.

I was reminded today of how rounding is not given first class treatment in Java. If you want to round an int or long, I suppose some division, casting, and multiplication can suffice, but for float and double, we must resort to the unwieldy BigDecimal class.

Consider the code needed to convert a float of unknown precision to a float with 2 places after the decimal point:

myFloat = (new BigDecimal(myFloat))
    .setScale(2,BigDecimal.ROUND_HALF_UP).floatValue();

Now granted, the rounding flexibility of java.math.BigDecimal is nice, but it’s at least a bit wonky to create 2 additional objects and one extra primitive just to accomplish such a trivial task. (One BigDecimal is created with new(), another with setScale – BigDecimal is immutable.)

Many developers would have you believe that somewhere along the way, enterprise Java slowly evolved into something that could no longer be done simply. Instead, it was the problems that became less simple. As the problems became more difficult so did the solutions. Servlets arrived, but it was ugly writing html code out in Java code, so we added JSP. Writing Java code in our JSP was ugly, so we remembered MVC. We got tired of writing our own MVC, so we adopted MVC frameworks, and evolved them to meet all the needs of all of the users out there. At the root of it all, though, peel back all of this, and you can still write a servlet if you like. If you want to write a transactional, scalable, remoteable component you can do that by hand. Or you can use an EJB.

Bruce Tate writes an analogy comparing J2EE to riding a mountain bike. In his analogy, he suggests that we are climbing an uphill trail of overly complex technology, and that it’s time to choose a simpler, easier trail. I suggest, rather, that the applications we’re building are the trail, and that our choice of technology is the choice of what gear to use in attacking that trail. When climbing a steep hill, low gears are necessary so we don’t fall over. Trying to use that same gear on a flat or downhill slope will leave you exhausted. Much like a developer would feel if they used entity beans behind stateless session beans behind a session facade called remotely from an MVC web tier, perhaps even JSF, simply to accomplish a 10 screen CRUD application (and don’t forget JMS for logging).

He does make the point, “Most applications are simple, and we don’t need to go through artificial steps to complicate them.” This is absolutely true, and is far more important that the popular suggestion that Java will collapse under its own weight. In riding a mountain bike, even on the long journey of your career, you may not use every gear, but it’s good to know that if you needed it, it’s there. Some speeds on the J2EE bike are still needed, some will eventually be removed. The EJB expert group recognizes that perhaps EJB make you pedal too hard for most projects, hence we have EJB3 coming as a potentially simpler way.

We don’t need a new bike. We need fewer vendors pushing overkill solutions, fewer managers forcing their teams into first gear just in case they need to climb a big hill, and more practical developers looking to build the right system instead of building resume fodder. We need to choose the right technology for the projects, and that’s an old idea, not a new one.

Like the middle-aged father quoting rap lyrics, the JCP has apparently embraced Hibernate as the underlying persistence mechanism for EJB3 in an attempt to be hip, or at least relevant. The article seems strewn with misinformation: “as database vendors also, they probably prefer Hibernate to JDO because it uses the SQL syntax of the underlying RDBMS—which allows applications to be locked in to a specific database vendor”, and much of the article is based on the author’s reaction to Marc Fleury’s grandiose merketing statements. It’s also a tainted article in that the author has a horse in the race as a member of the JDO 2 expert group.

That being said, this decision, if true, is a curious one to say the least. The entire EJB3 proposal does smack of desperation – EJB have been so broadly panned in community discussion and even in print (“Bitter EJB”) that something needed to be done to keep them from fading into obscurity. In many ways, a radical departure was needed – lightweight containers and transparent persistence have taken so much mindshare that without an answer from the JCP, the only standards would be de facto ones (Hibernate, Spring, etc). JDO 2 has the promise of being up to the task of transparent persistence without requiring a full J2EE container, but apparently the two expert groups have chosen to be adversaries rather than allies. So they couldn’t use JDO – that would require the two groups to play nice. They didn’t want to make up a new standard – people would ignore it. Instead, they chose Hibernate, certainly helped by Gavin King’s presence in the EJB3 expert group (his work on Hibernate is to be applauded). In doing so, certainly they are hoping and praying that they can instantly capture mindshare by hitching themselves to the buzz-heavy Hibernate, and hoping to recapture all the current Hibernate users as EJB users.

It’s well-known that Gavin has technical beefs with JDO, but salvaging EJB is a far taller order than overcoming minor technical disagreements in the JDO spec. This decision is a dangerous one. Weaving a vendor’s proprietary technology into the heart of a J2EE spec throws too much power to one vendor – I wouldn’t put that trust in BEA, IBM, Pramati, etc. It is even more unstable when that vendor is the unpredictable JBoss group. To my knowledge, it would be a first – the first adoption of an independently developed framework as a part of a J2EE standard (although Groovy is trying as well). Let’s hope that, as Cameron suggests, they are merely pulling ideas from Hibernate rather than adopting it. Time will tell whether EJB3 emerges as a goofy 45 year fronting Ecko gear or a svelte technology borne of an extreme makeover gone right. EJB are in dire straits, only dramatic action can make them relevant again, but the wrong drama could lead to an epic power shift that nobody needs.

Yet another reason frames are evil. The “normal” pattern for a Struts/Tiles app is that your application contains links that point to Struts actions. The action executes, and maps the result to an ActionForward that points to a Tiles template. The Tiles template then pulls in the pieces of the view (header, menu, content, etc) and sends the result to the user.

Now imagine the same thing with a frames application. In frames, the browser first pulls down the frameset in an HTML document, then reads from the HTML document where to retrieve the contents of the individual frames, in separate requests, from different URLs. So if you call the Struts action and then forward to the Tiles template, whatever data you may have stored in the request is completely useless – the request the data was placed in was used to grab the frame layout, and this new request to load your content doesn’t contain the information you wanted. (This does assume that you reload all frames with each request.)

So what are your options? Well, you could base your whole application on the premise that users will ALWAYS come in through the front page, that you will always change only one pane at a time. If you do this, your links can now point to a Struts action with a target of the frame the content will go in. Unfortunately, this means 1) No bookmarking, 2) you can’t switch to a non-frames layout without substantial redevelopment, and 3) if you want to change the content and menu with the same link, you have to resort to some wonky Javascript workaround.

The other option is similarly lame, more complex, and also not functional. You essentially have to split your application logic into 2 categories, data you want to read, and data you want to submit. On a submit, you still submit directly to a working struts action. If you want to populate data into the view, however, your initial Struts action has to be a forward to a Tiles definition, and you have to make the tile region point to the Struts action that fetches the data, then have that forward point to the actual JSP to be loaded. In this case, if you want to have an interaction that submits data and then includes information from that interaction on the response screen, you have to find a way to pass that data around rather than putting it in a request.

Frames were broken the day they arrived. The way they completely hose dynamic web pages is a further indictment of their uselessness.