JDO 2.0 draft available, start your engines.

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.


Media, Reagan, and Abu Ghraib

Dan Rather and Tom Brokaw are tired of talking about Reagan. Of course you won’t hear them get tired of covering Abu Ghraib. While the local print rag at least sees fit to feature Reagan coverage at the top of their web page, the editorial board won’t let it go. While they’ve pushed out weekly streams of articlers and columns on Iraq, usually highlighting the negative, only one positive opinion piece has been written about Reagan, written by Jim Wooten, the token conservative on the editorial board. Combined with Rather and Brokaw’s statements, you get the feeling they’re covering Reagan, who was easily the greatest of the living Presidents, and either the 11th or 6th best U.S. President ever depending on who you ask, out of a sense of obligation. They’d rather get back to talking about the so-called “reality of Iraq”, which really means “what’s going poorly in Iraq”. Reality would require an even-handed look at Iraq, including what’s going right.

The events of Abu Ghraib are in fact despicable. What is incredulous is how the mass media so quickly ignored the OTHER events of Abu Ghraib that didn’t involve prisoners. Soldiers were engaging in group sex and taking pictures. Clearly their chain of command didn’t know about this, so why is it so necessary that their chain of command knew about the “torture” (which was actually just fear and humiliation). Lynndie England’s failure to name names in saying that her “chain of command” ordered the torture would tend to indicate that nobody ordered it, that she’s bluffing. So why can’t we get over it? Ensure that a full investigation is done, that those responsible for the senseless humiliation and intimidation are brought to justice, and let us know when something significant develops.

Then, let’s start a separate discussion on the role of structured and deliberate interrogation techniques (note that Abu Ghraib seemed to be more for sick pleasure than information gathering). I don’t know the subtleties of the Geneva Convention enough to debate policy against treaty. I do know that if threatening an enemy officer with a snarling german shepherd saves a few American lives, I don’t have a problem with that technique. Perhaps I’ve watched a bit too much 24, but I’m inclined to say that I’d be willing to allow a good bit more in an interrogation if the subject knew of a major threat to innocent lives. The media criticism of the use of torture in any context fails to provide alternatives. How are we supposed to get information we need to protect the lives of our armed forces and innocent Iraqi and U.S. Citizens? Are we supposed to repeatedly ask nicely and hope that prisoners decide to give up information? That’s absurd. At some point, some sort of coercion is needed, but it would seem that all forms of coercion are “bad”. Should significant pressure be placed on an Iraqi foot solider? Probably not. He’s unlikely to have actionable information. But a senior officer, weapons researcher, or terrorist operative? Reasonable, controlled techniques are needed. What those should be is up for debate, but it has to be something better than “pretty please?”

What’s truly sad is that the media is so disenchanted about having displace their overblown coverage of these events and other stories designed to turn the public against the war in Iraq to cover the legacy of one of the greatest Presidents of the 20th century for what hasn’t even been a week. How are we supposed to get objective coverage when even the biggest names in broadcast news would rather hammer the “reality in Iraq” than the legacy of a great man?


Super Regional – Tech vs. Georgia

My excitement is on the rise for this weekend’s college baseball matchup between my alma mater, Georgia Tech, and No Name University. Tickets were apparently tough to come by, selling out within the first hour of their sale to the general public (available to GT donors and season ticket holders since Monday). That the university from Athens only reserved HALF of their 600 ticket allottment in a series that will decide a berth in the College World Series is both sad and amusing – only family and friends of players received tickets through UGA. Overall, I’m guessing this will lead to a huge home field advantage for Tech.

Russ Chandler Stadium is a great venue for one of the purest major college sports, baseball. Although we won’t get the beauty of a night game in downtown Atlanta, the 2 pm Friday start will give me an opportunity to cut out of work early, and perhaps lunch at Junior’s. Saturday and (hopefully no need for) Sunday noon starts mean nice sun and brunch tailgating. It’s almost like football season.


Convoluted Rounding in Java

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))

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.)


Baseball Draft Timing Irresponsible

Wait until the College World Series is over. Is that so hard? As if professional baseball isn’t so self-important already with its super-size 162 game season and its incessant whining about “tradition”. (Before inter-league play, precisely what was so interesting about playing the same 13 or 15 teams an average of 10+ times each? Why not cut that number in half so people can even think about caring about the importance of a single game?)

Now we have the baseball draft, where they begin picking the 17 year olds that they’ll send to southeastern Idaho for 4 years where they can stock groceries and hope they get moved up to AA ball eventually. The real problem is that, in case they haven’t noticed, some of the kids they’re drafting – the ones in college, haven’t finished their seasons yet. For most student-athletes, this doesn’t matter. They don’t have a chance of a career in the pros, but what of the ones that do? Just why should Vanderbilt’s Jeremy Sowers give 110% toward next weekend’s super-regional matchup with Texas when he’s already the number 6 pick in the draft? I’m not suggesting that he’ll throw in the towel, but he certainly doesn’t have the same motivation to put everything on the line. I know when I was in my final semester in college, it became much harder to care about classes once I’d locked down my post-graduation job.

These players and their teams should have an opportunity to focus on getting to and winning the College World Series, on doing and showing their best so that they can win games, and possibly improve their value in the draft. Instead, for the top prospects, the race has been run. Almost nothing they do now will affect their paycheck. Hopefully, pride is enough to motivate them, but why risk it? Drafting DURING these games harms the college game. Waiting would harm nothing. In just 3 weeks, a national champion will have been crowned. Colleges have already signed their recruits for next year, and Spring training is still be 8 months away. The NFL doesn’t draft during bowl season, the NBA doesn’t draft during March Madness. MLB’s choice to draft during the college post-season is a distraction, and a sample of the arrogance that has led to the league’s declining popularity.


Who Deprecated My Servlets?

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.


EJB3 to use Hibernate? Desperation and politics.

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.


Struts, Tiles, and Frames don't mix

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.