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.