There's been a lot of a hubbub about POJO persistence lately what with JDO 2's failed first vote and the EJB 3.0 EG hammering out what that's supposed to look like. A lot of people are (rightfully) concerned about competing standards under the JCP umbrella. One or the other should be the Sun recommended method for persistence of objects inside a Java-based application. But here's a question I haven't seen asked yet: Why not put that framework in the j2se like the logging was?

Let me start by saying that I'm not (necessarily) recommending this approach, but it does have some interesting benefits. Some would argue that persistence is an enterprise concern and belongs in the j2ee bundle. But you only have to look at java.sql to see that not everyone believes that database interaction belongs solely to j2ee applications. By having persistence as part of the j2se, it lightens the burden of configuring a system for persistence and figuring out all the component dependencies. Having it in the j2se bundle immediately makes it available to every java developer and application. I'd be willing to bet that all but the simplest of applications need some form of data persistence whether it be to a full-blown database or a simple XML backing store. For this to work, of course, the data store would have to be abstracted out much the same way that JDO and hibernate abstract out what database is being used.

Now, on the flip side, many people complain that the j2se bundle is already too large and that's a valid observation. So perhaps the way forward would be a smaller componentized j2se distribution system where users can pull down the components needed for a given application. But then, isn't that what we already have to a large degree with the various JCP projects? Perhaps Sun just needs to work to formalize and centralize the mechanisms available for gathering the dependencies: perhaps an on demand, automated download based on the configuration for a given j2se/j2ee install. Rather than downloading the entire bundle, a user (or, more likely, a system administrator) would simply download a kernel and then configure the desired components. The VM (or some new admin tool) would then fetch the jars for the configured components. Such a system could then be independently upgraded rather than having to upgrade a system whole cloth.

That might be the route to go as I the larger problem I see with many of the various projects is one of system configuration and dependency management.

When considering a potential contract, I started wondering about how I would develop it. This shop I know is windows and there's very little chance they'd migrate to anything else so I started thinking, "Should I use C#?" It has certain benefits, to be sure. But just because I don't think they'll ever change operating systems, why should I limit them? Maybe they'll see the light and switch to Linux or OS X. So then what?

I considered using the Eclipse framework as a platform to crank out the app. That was an attractive option as it gives (at least according to the hype) near native speed on the desktop. But, then, eclipse also gets knocked for being slow on Linux even with SWT. On the other hand, I use IDEA as my IDE and it's as snappy as I could ask for. So when it comes down to it, I think I'll stick with Swing. It's a known quantity and available anywhere Java is. I don't really have to worry about deployment/installation issues like I would with the native components of a SWT app. The JDIC projects are starting to give Swing real muscle on the desktop. Now what would be really nice is a Swing based framework like Eclipse offers to build applications on top of. Maybe I could just port Eclipse to swing. :)

I finally put the new website up today. It took me a while because I kept going back and forth on how to "power" the site: "Should I use a CMS?" "Should I just hand roll it?" etc. I finally decided to build a simple ant driven site to build all the content for the articles and just use sitemesh to deal with the decorations. It's a bit more hands on that a CMS probably would be long term, but I decided that a CMS was too much for the site and I couldn't find one that would let me do what I wanted to do: namely, write articles online and push them up when they're done. My system, however simple it may be, lets me do that with complete control over every aspect of the site. Now I just need to tweak the UI a bit...