Skip to content

An Easier Java ORM


There is no doubt that Hibernate is the dominant ORM for Java applications. There are Hibernate conferences and Hibernate user groups. It even has its own shelf at Barnes and Nobel. However, I have always found it suffering from a fatal flaw: it’s incredibly complex. Even accomplishing the simplest of functionality requires hundreds of lines of code, reams of boiler-plate POJO definitions, and a fair share of XML. Granted, it’s probably simpler and more scalable than using JDBC in its raw form, but I still think it makes things harder than they have to be.

This has been a common theme throughout most ORMs in any language. Even various Python ORMs, touted for simplicity and power, still remained burdened with either cryptic syntaxes, or mountains of boiler-plate. This general failing is probably the single most important factor which has contributed to the success of Ruby on Rails.

Rails is nothing without its flagship component, ActiveRecord. AR provides an incredibly simple and powerful database wrapper layer which makes working with almost any schema simple and intuitive. Granted, migrations are a bit weird and it’s performance is far from satisfactory, but the fact remains that it’s much easier, quicker (and thus cheaper, at least in the short term) to develop a database-reliant application using ActiveRecord than it is to build the same application on top of Hibernate or iBatis. This has been carried to such an extreme that developers have taken to using ActiveRecord on top of JDBC through JRuby just to handle the database layer of their Java application. Clearly a better solution is required.

Much of ActiveRecord’s power is drawn from the fact that very little code is required to interact with the database. For example, extracting data from a hypothetical people table in a database is as simple as:

class Person < ActiveRecord::Base
puts Person.find(1).first_name   # roughly == SELECT first_name FROM people WHERE id = 1

Obviously, the first_name method doesn’t exist in the Person class. This code is using a feature of Ruby which allows for methods to be defined at runtime (or rather, not defined and just handled). It should be apparent how much this could simplify database access, and how unfortunately inapplicable it is to Java.

Fortunately, the principles of ActiveRecord are not entirely irrelevant. The Java reflection API contains a little-known feature called interface proxies. It allows code to define a dynamic implementation of a given interface which handles method invocations in a single, dynamic location. It’s not quite dynamic method definitions, but it is dynamic method handling and it eliminates a lot of boiler-plate.

So what good does this do us? Enter ActiveObjects!

ActiveObjects is a Java ORM based on the concept of interface proxies. The whole idea behind it is that you shouldn’t have to write any more code than absolutely necessary. In fact, ActiveObjects was designed from the ground up to be dead-easy to use. Here’s a rough approximation of the previous ActiveRecord example, translated into Java using the ActiveObjects ORM:

public interface Person extends Entity {
    public String getFirstName();
    public void setFirstName(String firstName);
EntityManager em = new EntityManager(jdbcURI, username, password);
Person p = em.get(1);
System.out.println(p.getFirstName());    // executes "SELECT firstName FROM person WHERE id = 1"

Isn’t that refreshingly simple? With the exception of placing the appropriate JDBC driver in the classpath, that’s all there is to using ActiveObjects. AO automatically detects the database type from the JDBC URI and loads the appropriate driver. If you have placed a pooling library on the classpath, it will be used to pool the database connections. You’ll notice the Person implementation is created by the EntityManager instance corresponding to the (presumably existing) database row, and the SQL is automatically generated and executed, typing the result and returning it from the method. AO even uses PreparedStatement(s) for maximum performance (currently unsupported by ActiveRecord). And if we were to call the setFirstName(String) method, an SQL UPDATE statement would be automatically executed based on the data specified.

Of course, simple CRUD operations do not an ORM make. For one thing, it’d be really nice to be able to automatically generate database-specific DDL statements, ala Hibernate and ActiveRecord. Coolly enough, ActiveObjects allows for this too:

System.out.println(Generator.generate("../classes", "jdbc:mysql://localhost/db", "test.package.Person"));

This would output:

    firstName VARCHAR(45),

With a different JDBC URI, the DDL would be different. ActiveObjects completely insulates the developer from any database inconsistencies. In fact, the only steps needed to switch to a different database are to place the appropriate driver on the classpath, and to change the URI.

To round up our little tour of ActiveObjects, it’s worth looking at relations a bit. In ActiveRecord, relations are specified using the has_many and belongs_to methods. Hibernate uses annotations/custom javadoc syntax to accomplish roughly the same thing. In ActiveObjects, things are nice and clean:

public interface Person extends Entity {
    public String getFirstName();
    public void setFirstName(String firstName);
    public House getHouse();
    public void setHouse(House house);
public interface House extends Entity {
    public String getAddress();
    public void setAddress(String address);
    public Person[] getPeople();

With just the above entity definitions, calls can be made to instances of Person, passing the House instance to store. Likewise, House#getPeople() can be called, which will return an array of all Person instances associated with that House. Obviously, the Java instance itself isn’t being stored in the database, but rather the houseID INTEGER value is persisted, through the restriction of the appropriate foreign key.

It almost seems magical when you first start using it. :-) I’ve written two test applications (not downloadable, but included within the ActiveObjects SVN) which illustrate the framework’s potential more fully. Also, I’ve been using ActiveObjects as the basis for a reasonably complex Wicket application deployed in the “real world”, and I must say it’s performed beautifully.

Now here comes a moment of bad news: it’s not fully documented yet. Since it’s only on its 0.3 release, I’ve been more interested in squashing bugs and adding features than writing javadoc, though I assure you it is on my agenda. There are a few brief (and somewhat dated) examples on the website, as well as partial javadoc for the EntityManager class. Thankfully, the framework itself is remarkably intuitive and very easy to pick up.

There’re so many more cool features I would love to have shown here, but unfortunately all bloggers have sworn in blood that they will not extend their posts beyond 1500 words. If you are interested, I’ll write a follow-up post going into further detail about the framework (including the more performant SaveableEntity super-interface, which does not execute an UPDATE on every setter call).

Do yourself a favor and take a look at the API and examples. Once you get used to the simplicity of Entity interfaces and non-configuration of database connections, you’ll never look back.

Wicket TextileLabel


Well, first I must apologize for not updating my blog in some time. Loads of interesting (and time consuming) things have been happening recently, specifically related to my employment as well as a rather jam-packed holiday week in the US. On a slightly different (but related) note, I resigned from my full time job and am once again “programmer for hire” (if you’re interested, you can drop me an email: djspiewak [AT] gmail). Thankfully, all the closing details seem to be in order, so I’ll finally have a little more time to devote to this blog as well as to writings on EclipseZone.

In that vein I’ve spent a bit more time with Wicket (now Apache Wicket) recently, and I have to confess even more impressed with it than I was a year ago when I first looked at it. The separation of markup and code is a powerful concept that no other framework seems to have achieved to the same level without massive libraries of custom tags. For those of you who aren’t already familiar with Wicket, it’s an Open Source, component-based web framework. You create pages in Wicket by writing a standard HTML file, adding a wicket:id=”yadayada” attribute to the dynamic elements, then you add the corresponding component instances to the Page instance in code. No Java in your HTML, no HTML in your Java.

One of the things I stumbled upon in my latest run at the Wicket is the limitations of its MultiLineLabel component. MultiLineLabel lets you display large blocks of text with the characters appropriately escaped and all line breaks converted to proper <p></p> blocks. It’s not a complicated component, and this is glaringly obvious if you actually need something a bit more substantial.

The site I’m using to experiment has a need for large blocks of (preferably) formatted text. At first, I figured I’d just throw a MultiLineLabel up and call it done. However, the need for formatting seemed a bit more pressing, so I began to look at alternatives. And it occurred to me that perhaps the simplest way to enter formatted text is to use Textile. Unfortunately, this means I need some way to render Textile into HTML within Wicket.

After some Googling, I was able to positively ascertain that there are no Wicket components which provide Textile rendering. Not being one to give up there, I decided to roll my own. After all, one of Wicket’s major selling points is that it makes custom components dead easy, right?

Well, seems the hype is justified in this area too. Although, I must admit the documentation is sorely lacking in this area. I ended up cracking open the source for MultiLineLabel (which was surprisingly readable) and discovering that the key is to override the onComponentTagBody method. With a little more Googling, I found PLextile, which is the most complete Java Textile rendering library. A few minutes of quick hacking later, and I came up with this:

protected void onComponentTagBody(MarkupStream markupStream, ComponentTag openTag) {
    String text = (String) getModel().getObject();
    if (text == null) {
        text = "";
    replaceComponentTagBody(markupStream, openTag, postTextilize(new TextParser().parseTextile(text, true)));

PLextile handles all the heavy lifting here, and parses out just about everything just fine. It’s main stumbling point is how it handles line breaks. According to Why’s comprehensive Textile reference, line breaks should be handled by wrapping the sections into <p></p> blocks, whereas PLextile was inserting <br/> tags. Quite frustrating, let me tell you.

I considered using RedCloth (Why-the-Lucky-Stiff’s Ruby Textile renderer, wrapped by Rails for the famous textilize method) through JRuby and Java 6 embedded scripting, but it seemed awfully heavy to fire up an entire JRuby interpreter instance just to parse some text, so the decision was made to steer away from that. Instead, I wrote a post-processor for PLextile (hence the postTextilize method in the example above). This method is actually where most of the code is for the component:

private String postTextilize(String textile) {
    textile = "<p>" + textile + "</p>";
    textile = textile.replace("<br />\\r<br />", "</p><p>");
    textile = textile.replace("<br />", "");
    return textile;

Anyway, wrap it all up into a WebComponent subclass and it’s ready to use in a page. Swap TextileLabel for your former MultiLineLabel usages, and you’re ready to go!

You can download the finished component here.

JRuby: The Future of Scalable Rails?


So I was talking earlier today with my good friend, Lowell Heddings, regarding certain annoyances we had with web frameworks. The conversation started talking about the difficulties of developing PHP applications due to the lack of a debugger, but (as conversations on web frameworks are wont to do) eventually the migrated to Rails.

I mentioned how I’d always been a bit distrustful of a web framework which ran on the one-request-per-persistent-process model. My reasons for distrusting this sort of framework were mainly related to performance and scalability, but Lowell brought up an interesting point that I hadn’t considered before: process-shared sessions.

See, because Rails runs as a parallel share-nothing process (i.e. the mongrel instances don’t share memory state with one-another), trivial in-memory data can be a bit of a problem. Also, caching to disk can be a bit problematic since there are multiple processes attempting to access the on-disk data simultaneously. I’m sure many clever solutions have been mooted to solve this problem, but (I think) a new one occurred to me as we were discussing the problem. (caveat: I haven’t fleshed out this solution at all with any code. I’m posting it because Lowell thought it was an idea worth sharing) :-)

My solution to the problem drops back into one of the hottest topic in Ruby today: JRuby on Rails. JRuby allows you to run Rails applications in a Java-based and integrated environment, even to the extent of using existing Java tools, libraries and process containers. An ancillary project to JRuby even allows you to package up your Rails application within a WAR and host it directly within a Java application server like Tomcat or Glassfish.

Packaging Rails as a WAR obviously necessitates a bit of configuration that wouldn’t normally go into the deployment of a Rails application. For example, if you want to serve multiple requests with a Rails app concurrently, you would run multiple Mongrel instances and use an Apache mod_proxy configuration which would proxy requests to available server processes. Java web application, while they do run on the persistent-process model, are designed to be multi-threaded, rather than multi-process. Thus, Java web applications automatically scale to involve concurrent requests since all that is required is the spawning of a new thread within the application server.

Rails however, is designed to be hosted as a separate process and would have to be extensively modified to support this kind of scaling directly. The solution found by the JRuby-extras project is to allow multiple Rails instances to be controlled by a single Rails app WAR. The number of instances is controlled by a configuration option within the web.xml config file within the WAR. Thus, the JRuby WAR will spawn a new instance of the JRuby interpreter for each Rails process (as Rails expects), all hosted in separate threads within the same JVM instance, controlled by the Java app server. Thus, instead of going to all the hassle of configuring a new Mongrel instance and adding a mod_proxy rule to scale your Rails app, all that is necessary is to change a value in an XML file and to redeploy.

This single-process encapsulation of Rails in this way allows us to provide a solution for Lowell’s shared data problem. Instead of storing shared data (like application sessions or cached values) within the Rails process itself, the Rails application should use a Java class (hosted within the same WAR) to store the data. Thus, all shared application data should be stored at lower level than Rails, within the Java process itself. Java has some very solid concurrency APIs which would allow this sort of shared state without data corruption.

JRuby-on-Rails Diagram

As the application scaled and the shared data requirements increased, the SharedCache class (as we’ll christen it) could be modified to cluster, using Terracotta. The Rails WAR itself is already transparently clusterable through Java application servers like JBoss. As Lowell put it, it’s like an infinitely scalable memcached, without all the fuss.

Well, it’s a thought anyway…

Fuse 0.4 Release


Some of you may know that I worked (and have been working) on a little open source project with Romain Guy called Fuse, hosted under SwingLabs at (not related to the Filesystem in Userspace project) It’s a pretty neat project that was actually started by Romain to assist in the development of the Aerith demo (shown at JavaOne 2006).

The whole idea behind the project is to provide a simple, easy to use resource injection library. Resource injection is different than dependency injection for a number of reasons (explained in more detail on the project page), but suffice it to say that this is an incredibly useful little library that makes centralizing your resource configuration a piece of cake.

I started using Fuse on a regular basis at about the same time I stopped developing Fuse on a regular basis. :-) After I started my latest contract work (back in early last July), I no longer had enough time to devote to the project, so it went by the wayside almost immediately after the 0.3 release. Romain too, was working on various projects (including the book Filthy Rich Clients, coauthored with Chet Haase), so the project really would have just lain dormant for a while, except that I was actually using Fuse in the project I was working on.

This was really the first time (that I know of) that Fuse was used in a solid, large scale application. Those of you that have developed experimental libraries in the past know that you don’t really know that an API is working the way you want until it’s tested in a bona fide application. Well, that was true with Fuse too. In the process of using Fuse, I was able to isolate and fix a number of pesky little bugs that had slipped through our unit testing, as well as improve performance immensely.

Most of the changes made to Fuse were bugfixes, but the big ticket new feature is transparent caching of loaded resources. If a resource has the same value and type as one which has already been instantiated and injected, that instantiated instance will be used. Since Fuse is designed for (though hardly limited to) the injection of immutable resources, this works out really really well. I’ve noticed a huge return in performance from this simple change (alla GUI load times 2x as fast).

Most of these changes (including caching) were made gradually over the last 10 months, so there wasn’t really a clear line where we could say “this constitutes a release now.” For my project, I was just using a custom build of the CVS HEAD version of Fuse, rather than the 0.3 “stable” release. Ironically, it had gotten to the point where I was actually telling other people to use the HEAD version since I knew that it would be more stable and performant than the 0.3 release.

Eventually (as in yesterday), Romain and I decided that there was no real reason to hold off on a release any longer. While our documentation may still be woefully out of date, and while neither of us remembered enough changes for an impressive RELEASE NOTES, we still think that pushing out 0.4 was the right choice.

So, the 0.4 release is now up on the servers and available for download here. If you’re interested in Fuse, or if you’re using Fuse already (especially if you’re using Fuse already), I suggest that you run over to the download site and grab the latest version. There were no API changes in this release, so it should just be a drop-in replacement for the 0.3 version you’re using now.

Oh, if you’re interested in Fuse, there’s some very good explanatory documentation on the project page. It’s a bit out of date (I don’t think it mentions auto-injection even once), but it does a good job on the concepts and provides a solid starting point for anyone wanting to try the library for themselves.

DZone Gets a Facelift


Well, after months of development work, Rick and Matt have finally deployed their DZone site redesign to the production servers. It’s been running on a dev server for a while now, whilst those of us “in the know” tried to break it or offer constructive criticism. However, I think we’re all quite relieved that it’s finally up at So, without further ado, a brief look at the new look!

DZone New Look The first thing you’ll notice is that it’s blue, very blue. The old look was really more of a green and yellow deal with a generous dose of white (everyone’s favorite). The new look has blue borders, blue gradients, blue rollovers, and subtle blue-colored hovers. There are rounded corners galore, high resolution avatars, improved comments LAF and a neat new scrolling feature which I’ll touch on a bit later. Probably the second thing you’ll notice is that your voting options have increased, and your complain option has disappeared. People were overusing the complain feature (especially “just plain lame”), so it was removed and replaced with “down vote”.

This release also sees support for “unvoting”, both up and down. How many times have you clicked on the vote header when you were actually going for the thumbnail? Well, now, you can just unvote your mistake and move on (or more preferably, vote more accurately and more prolifically). This feature was discussed at length amongst the DZone staff, and it was decided that this really was a good idea. There are no restrictions on unvoting yet, but if we see a significant amount of gaming surrounding the feature, steps will be taken…

The scrolling feature is pretty sweet too. To test it out, scroll all the way to the bottom of the front page. After a moment’s hesitation, the next several links will load automatically and populate into your browser (by the power of the mighty AJAX). This works on any link aggregation page (FP, the queue, saved and shared).

I have one more feature to mention before I close this already lengthy writeup: sharing and saving. You can now share links (Google Reader style) easily as you traverse the front page (or more preferably the queue). Shared links go into your profile’s “shared” section, which has its own URL you can send to your friends. It also has its own RSS feed which you can use to more conveniently spread your links to the far corners of the globe.

Saving is a similar feature which allows you to mark a link for inclusion into your “saved” section, which is not a public area. This way, you can mark things as “for later attention” without having to vote, comment, share or otherwise publicly dog-ear the link. I don’t know about you, but I will probably use this feature constantly.

Oh, one important thing to note: everyone should re-upload your avatar. DZone used to only support 16×16 images for your avatar. The new maximum size is 80×80, but there are numerous scaled versions which are saved. If you have a high resolution image for your avatar, upload it asap to get the clearer quality on all your posts.

There’s so much more in this release that I haven’t had a chance to tell you about. Hopefully, one of the other DZone staff (I’m crossing my fingers for Rick) will do a more complete writeup in the near future detailing the new features more thoroughly than I could here. Enjoy the new interface!

P.S. I forgot to mention it. now supports OpenID login. It only allows you to vote and comment on links, since OpenID doesn’t actually do anything more than authenticate you. To do anything more (like post or share), you have to upgrade your login to a full DZone username. But still, it’s a cool leap into a burgeoning new technology.