My pal Greg work for Sleepycat Software, who just released Berkeley DB Java Edition. Berkeley DB is some cool technology; quite a few popular sites use the C version of Berkeley DB in their presentation layer (in fact, Berkeley DB is used in a huge number of places, including Subversion), as a cache against raw data stored in Oracle or a backend system. It's anything but a relational database ... its a high-performance, transactional, embedded database. It's a way of storing large amounts of binary data, which just might happen to be serialized Java objects.
The Java Edition adds a Java-friendly API ... Berkeley DB databases end up looking like Maps and other Java collections. Or you can get more down and dirty and control exactly how objects are serialized into, and de-serialized out of, Berkeley DB entries.
There's a lot of talk about J2EE without the complexity of J2EE, thus things like Spring and HiveMind ... the sacred cow of EJBs (both session and entity) fall away when you find a different, better way to organize and componentize your code. Most of us still assume that the only way to store our data is in a relational database, and then get involved in an Entity EJB vs. Hibernate vs. JDO vs. TopLink battle ... when, in many cases, all we want is a simple way to store and retrieve Java objects. The relational database becomes an assumption, somehow evading questions of cost (of licensing, of adminstration, of maintenance, of hardware), use cases, requirements ... it's another sacred cow waiting to be slain. If you are creating a typical application, where the application itself is the only use of the database, then an embedded database may be the better, faster, more efficient, cheaper, zero-administration approach.