What’s Wrong With Java Part 2

21. July, 2007

OR Mapping With Hibernate

After the model, let’s look at the implementation. The first candidate is the most successful OR mapper combination in the Java world: Hibernate.

Hibernate brings all the features we need: It can lazy-load ordered and unordered data sets from the DB, map all kinds of weird relations and it lets us use Java for the model in a very comfortable way: We just plain Java (POJO‘s actually) and Hibernate does some magic behind the scenes that connects the objects to the database. What could be more simple?

Well, an OO language which is more dynamic, for example. Let’s start with a simple task: Create a standalone keyword and put that into the DB. This is simple enough:

// Saving <tt>Keyword</tt> in database
Keyword kw = new Keyword();
kw.setType (Keyword.KEYWORD);
kw.setName ("test");

session.save (kw);

(Please ignore the session object for now.)

That was easy, wasn’t it? If you look at the log, you’ll see that Hibernate sent an INSERT statement to the DB. Cool. So … how do we use this new object? The first, most natural idea, would be to use the object we just saved:

// Saving <tt>Knowledge</tt> with a keyword in the database
Knowledge k = new Knowledge ();
k.addKeyword (kw);

session.save (k);

Unfortunately, this doesn’t work. It does work in your test but in the final application, the Keyword is created in the first transaction and the Knowledge in the second one. So Hibernate will (rightfully) complain that you can’t use that keyword anymore because someone else might have changed it.

Now, what? You have to ask Hibernate for a copy of every object after you closed the transaction in which you created it before you can use it anywhere else:

   1:
   2:
   3:
   4:
   5:
   6:
   7:
   8:
   9:
  10:
  11:
Keyword kw = new Keyword();
kw.setType (Keyword.KEYWORD);
kw.setName ("test");

session.save (kw);
kw = dao.loadById (kw.getId ());

Knowledge k = new Knowledge ();
k.addKeyword (kw);

session.save (k);

How to save Knowledge with a keyword in the database with transactions

Why do we have to load an object after just saving it? Well … because of Java. Java has very strict rules what you can do with (or to) an object instance after it has been created. One of them is that you can’t replace methods. So what, you’d think. In our case, things aren’t that simple. In our model, the name of a Knowledge instance is a Keyword. When you look at the code, you’ll see the standard setter. But when you run it, you’ll see that someone loads the item from the KEYWORD table. What is going on?

   1:
   2:
   3:
public void setName (Keyword name) {
    this.name = name;
}

setName() method

Behind the scenes, Hibernate replaces this method by using a proxy object, so it can notice when you change the model (setting a new name). The most simple soltuion would be to replace the method setName() in session.save() with calls the original setter and notifies Hibernate about the modification. In Python, that’s three lines of code. Unfortunately, this is impossible in Java.

So to get this proxy objects, you must show an object to Hibernate, let it make a copy (by calling save()) and then ask for the new copy which is in fact a wrapper object that behaves just like your original object but it also knows when to send commands to the database. Simple, eh?

Makes me wonder why session.save() doesn’t simply return the new object when it is more safe to use it from now on … especially when you have a model which is modified over several transactions. In this case, you can easily end up with a mix of native and proxy objects which will cause no end of headache.

Anyway. This approach has a few drawbacks:

  • If someone else creates the object, calls your code and then continues to do something with the original object (because people usually don’t expect methods to replace objects with copies when they call them), you’re in deep trouble. Usually, you can’t change that other code. You loose. Go away.
  • The proxy object is very similar but not the same as the original object. The biggest difference is that it has a different class. This means, in equals(), you can’t use this.getClass == other.getClass(). Instead, you have to use instanceof (the copy is derived from the original class). This breaks the contract of equals() which says that it must be symmetric.
  • If you have large, complex objects, copying them is expensive.
  • After a while, you will start to write factory methods that create the objects for you. The code is always the same: Create a simple object, save it, load it again and then return the copy. Apart from cut&paste, this means that you must not call new for some of your objects. Again, this breaks habits which leads to bugs.

All in all, the whole approach is clumsy. Really, it’s not Hibernate’s fault but the code is still ugly, hard to maintain (because it breaks the implicit rules we have become so used to). In Python, you just create the object and use it. The dynamic nature of Python allows the OR mapper to replace or wrap all the methods as it needs to and you never notice it. The code is clean, easy to understand and compact.

Another problem are the XML config files. Besides all the issues with Java XML parsers, it is always problematic to store the same information in two places. If you ever change your Java model, you better not forget to update the XML or you will get strange errors. You can’t refactor the model classes anymore because there is code outside the scope of your refactoring tool. And let’s not forget code completion which works pretty good for Java. Not so for XML files. If you’re lucky, someone has written a code completion for your type of XML config. Still, there will be problems. If there is a new version, your code completion will lag behind.

It’s like regexp: Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. — Jamie Zawinski

Fortunately, Sun solved this problem with JPA (or at least eased the pain). JPA allows to use annotations to store the mapping configuration in the class file itself. Apart from a few small problems (like setting up everything), this works pretty well. Code completion works perfectly because any IDE which has code completion will be able to use the latest and greatest version of your helper JARs without any customization. Just drop the new JAR in your classpath and you’re ready to do. Swell.

But there are more problems:

  • You must create a session object “somewhere” and hand it around. If you’re writing a webapp, this better be thread-safe. Not to mention you must be able to override this for tests.
  • The session object must track if you have already started a transaction and nest them properly or you will have to duplicate code because you can’t call existing methods if they use transactions.
  • Spring and AOP will help a lot but they also add another layer of complexity, you’ll have to learn another API, another set of rules how to organize your code, etc.
  • JAR file-size. My code is 246KB. The JARs it depends on take … 6’096KB, more than 40 times of my code. And I’m not even using Spring.
  • Even with JPA, Hibernate is not simple to use because Java itself is not simple to use.

In the end, the model was 5’400 LoC. A added a small UI to it using SWT/JFace which added 2’400 LoC.

If you look at the model in the previous installment, then the question is: Why do I need 5’000 LoC to write a program which implements an OR mapper for a model which has only three classes and 26 lines of code?

Granted, test cases and helper code take their toll. I could accept that this code needs four or five times the size of the model itself. Still, we have a gap.

The answer is that there are no or bad defaults. For our simple case, Hibernate could guess everything. Java could generate all the setters and getters, equals() and hashCode(). It’s no black magic to figure out that Relation has a reference to Knowledge so there needs to be a database table which stores this information. Sadly, defaults in Java are always “safe” rather than “clever”. This is the main difference to newer languages. They try to guess most of the stuff and then, you can fix those few exceptions that you always have. With Java, all the exceptions are handled but you have to do everyday stuff yourself.

The whole experience was frustrating, especially since I’m a seasoned Java developer. It took me almost two weeks to write the code for this small model mostly because because of a bug in Hibernate 3.1 and because I couldn’t get my mind around the existing documentation. Also, parent-child relations were poorly documented in the first Hibernate book. The second book explains this much better.

Conclusion: Use it if you must. Today, there are better ways.

Next stop: TurboGears, a Python web framework using SQL Objects.


Back from JaZOOn, Second Day

26. June, 2007

Well, modern medicine worked it’s usual miracle and my brain was much less clogged today. I went to the keynotes but left a bit disappointed. The history of the web and REST was nice to see but my interest in the past is usually reduced to use it as a source for cynical comments about mistakes that bite us today, and there wasn’t much in it for me in that regard. The second talk just contained nothing that I didn’t knew already. Well, you can’t always win.

Next, I went to see a software demonstration (Automated (J)Unit Testing) but I had seen that one before so I left early and attended Hibernate Search: Unstructured Search for Hibernate instead. The group around Emmanuel Bernard managed to extend the query API of Hibernate for Apache Lucene. Nice work, easy to use, looks promising. If you have a web application which allows users to search for something, this is definitively something you should try. Like Google, you can offer a single text field and the search results will be ranked in an intelligent way. Cool.

After lunch, I enjoyed the The Zen of jMaki. They have started to collect all and every JavaScript Web widget set out there, wrapped all of them in the same way, so they get much more simple to use. I don’t like JSP’s and tag-libraries but they have done a nice job and the demos looked real enough to believe that this can actually help.

In the same room, I watched David Nuescheler Blitzing the Content Repository: AJAX meets JCR. He developed a little JavaScript library called “R-JAX” which allows to create something that resembles CRUD with a JCR and a few lines of HTML. Since you can access the Content Repository via HTTP, all you need to do is to copy all files (JavaScript, HTML, CSS, etc.) into the repository and then make sure you use the right (relative) URLs and you were ready to go. This JCR stuff also looks very interesting. I hope I’ll find the time to have a closer look at Apache Jackrabbit one of these days.

Of course, when you do a lot of AJAX, you need to test it somehow. Ed Burns held the talk Java Platform Automated Testing of Ajax Applications where he compared four different tools to do this (some commercial, some OSS) and Webclient a.k.a. MCP (Mozilla Control Program) which allows to embed a web browser in a Java program and control it from a unit test (so you can load a web page, examine it, check AJAX requests, etc). GWT gets you only so far with their own testing framework (especially since it’s insane to setup and some things (like UI elements) can’t be tested at all. MCP solves all that but you have to deploy the webapp somewhere. Choose your poison.

Right now, MCP can only run Firefox (but they are working on getting at least IE on Windows). It would be nice to see the same integration on Linux using the IEs4Linux project. You did know that you can run IE on Linux, didn’t you? Not that anyone ever wanted (except for those web pages which stubbornly refuse to display correctly in Firefox … and for those, who insist on Flash 123.5 which will come for Linux in 2150 … but who needs them anyway).

The next talk was obvious: Java and Scripting: One VM, Many Languages. Rags Srinivas (with hat!) showed us around the Java Scripting API. Pretty low level presentation with little new information. I had hoped for more meat here. The only interesting he mentioned was that Sun doesn’t really care about dynamic languages per se. They care that as many of them as possibly run on the Java VM but not the languages themselves. That probably explains the strange maneuvering in the last months: Hiring key Ruby developers, working on standardizing Groovy (JSR 241 and then suddenly JavaFX is the Next Great Thing(TM). Actually, JavaFX just seems to be another building block in a growing forest (some would say swamp) of dynamic languages flourishing around Java.

Smells a lot like .NET (one runtime, any language you like) and probably makes sense. There are so many common problems (Singletons, DB access, HTML generation, mixing HTML and Java) which you can’t really do well in Java but perfectly well in other languages which don’t (have to) drag the Java legacy along. Java is ten years old, now, and it begins to show. GC was a fantastic new feature when Java came out, but today, every contender for the language of the next decade can do that. In Java, Beans, lists, maps and other, important types and concepts are second class citizens. To create a simple list and sort it, you have to write ten lines of code. In Groovy, you write:

def list = ['a', 1, 'b']

1 is of course turned into an Integer. Try that in Java 5 and the vital information, the data in the list, is drowned in syntax to club the compiler into silence:

import java.util.Arrays;
import java.util.List;

public class Foo {
    List list = Arrays.asList (new Object[] { 'a', 1, 'b' });
}

The sad part is that I had to start Eclipse to make sure that the syntax is correct. The Java code is six times as long and only 1/6th of that is actual information. The rest is only there to make the compiler happy. 😦

Back to Jazoon. I would have loved to attent the BOF’s, especially the ones registered by Neil M. Gafter about Java Closures and something else (I forgot) but I still wasn’t too well and didn’t want to risk to have to miss the last two days.

All in all, I enjoyed this day. My thanks go to the JUGS guys for organizing it.