Hibernate sometimes doesn’t like you at all.

You, the seasoned JDBC/Oracle developer. Some of you have learned that to query using HQL, you must use the hibernate equivalent object names, but still you persist (forgive me the pun, there,) in writing HQL that looks like SQL!! This is bad.

This is bad because your application is suffering. It’s suffering from verbosity, and from poor performance. Here is why - and here’s what to do about it.

Let’s take the following example HQL query:

select o from ManyToOneObject1 mo1,
ManyToOneObject2 mo2,
ObjectWeReallyWant o
where mo2.number = ?
and o.manyToOneObject2 = mo2
and o.manyToOneObject1 = mo1
and mo1.idOfSomeKind in
(select distinct mo3.idOfSomeKind
from [some subquery to do with filtering records])
order by mo1.descriptionField

This is an actual query from “the field.” The first thing that struck me as odd about the query was that it forcibly joined many to one objects instead of just asking for the object they wanted. Like this:

from ObjectWeReallyWant as o
where o.manyToOneObject1.number = ?
And o.manyToOneObject1.idFieldOfSomeKind in (select idFieldOfSomeKind from [subquery stuff here])
Order by o.manyToOneObject1.descriptionField

That’s a little easier to read. Either way we format the query, there is a big problem! When I looked at the SQL output in the logs of our application, I found one main query, followed by a very long list of select statements - one for each many to one record! But why? We can specify a “join” or a “select” for those mappings, and each setting will cause a different problem.

Join - we can have a cartesian product pulled back from Oracle. Hibernate eliminates the duplicates… but isn’t that what an INNER join is for?

Select - Hibernate will issue a separate select statement for each record.

Since neither of these options is what we want (an Oracle developer would look at our original HQL and think “inner join,”) we can tell Hibernate exactly how to fetch those relationships, as follows:

from ObjectWeReallyWant as o

inner join fetch o.manyToOneObject1

inner join fetch o.manyToOneObject2

where o.manyToOneObject1.number = ?
And o.manyToOneObject1.idFieldOfSomeKind in (select idFieldOfSomeKind from [subquery stuff here])
Order by o.manyToOneObject1.descriptionField

Using the “inner join fetch” HQL statement does what we expected the original statement to do - inner join. In our application this resulted in one statement, and no extra records.

To find this and other problems (Hibernate LOVES to left outer join, leading to cartesian product hell,) turn on your SQL output. (Use property: “hibernate.show_sql=true”)

Download the source code for the solution described below, here.

Anyone who has used Javaspaces has probably achieved a measure of success on one or two machines, then started to think more about how to deploy their solution. They might ask…

“How do the other computers get the libraries needed to execute work without my altering their classpath?”

This is where the “codebase” comes in. Javaspaces/JINI (and other Java/RMI technologies for that matter,) have the ability to query a url for a particular class or jar file, and receive bytes from that request. That downloaded bytecode can then be added to the ClassLoader of the running JVM. For further explanation, see this excellent article.

In short, an Http server can easily serve classes OR jar files. However, configuring the client computers to take advantage of the available code still exists as a task. The scenario can increase in complexity based on added jars and new tasks to execute. One day, three jars served up may be enough. A month from then, perhaps fifteen jars are needed.

If you didn’t read the article mentioned above - Note the following… If the codebase url ends in a slash - “/” then the url points to the root of a classpath. However, if the url is a list of jars, separated by spaces, then that specific jar is served by the Http server instead. It is possible to do both:

-Djava.rmi.server.codebase=”http://poobah:8080/MyClasses.jar http://poobah:8080/ http://poobah:8080/log4j1-X.jar”

So if we serve multiple jars to the network, then obviously this configuration path can become long. When mutliple machines start participating, maintaining the proper list can be a problem. Also, one hard coded Http server address is hardly fault tolerant. Some failover ability is needed and lord yes, some simplicity.

I ran into this problem myself while working with a couple Grid Computing frameworks and decided to make my life more simple. The code for my solution can be downloaded here, free to anyone who’d like to use it. (See the link at the bottom of this post.) The code is simple in concept and involves three components:

1. A small Http Server to handle requests.

2. A multicast listener (my own grid client processes extend a multicast base class that finds the url automatically on a LAN)

3. A jar indexer. The indexer should be pointed to a directory, and will recursively index every jar found in its path (including subdirectories.) One url is then needed to serve any class file found in any of the jars.

What this gives me, is the ability to always treat my jar serving http address as if it’s pointing to the root of an unzipped classpath, even though I may be actually serving classes from fifty jar files. Further, my grid clients can automatically find new jar servers if one of the jar servers goes down, since the servers themselves listen for requests and answer with their own url. This means that none of my grid computing remote computers require any rmi codebase configuration parameter at all. All I have to do to serve a new jar is drop the jar file into the path my jar server is indexing and it will be picked up and its classes will be available.

I am currently working on a more robust solution with a visual administration interface coupled with the ability to manage participating grid client tasks.

(repeat…) Download the source code for the solution described below, here.

Here’s a nice list of available frameworks…

Personally, when I look for a framework, I consider a few factors. One of the most important factors to consider is the time available married with the existing skills of the team. If time is tight, and your entire team knows Struts very well - maybe you use Struts!

Second, there are frameworks that approach very specific technical problems and there are frameworks that deal with all tiers of the architecture. Sometimes architecting an application is a mix and match situation. In Spring’s case this is very true. For example, Spring is multi-purpose and you don’t have to use all of its features. You can mix various combinations of the following frameworks - Spring, Struts, Hibernate, Stripes. Struts and Stripes are the only two that are mutually exclusive. This is just one example and I’ve left out Webwork as a valid framework - it’s a good one, too.

An architect may choose to implement an even more varied combination by implementing one tier in Java and the other tier in some other language. The possibilities are wide and varied.

In short, I look in two places from the get-go before I choose a framework or combination of them. My own experience and Google. Once I have a list of available frameworks I then consider the following factors.

1. Nature of the project - Mission Critical or more of an R&D effort? For more mission critical systems it’s good to make sure you have support and a mature framework that has a history of usability.

2. Skillset of the team vs. available time. (Need I mention apititude or lack thereof?)

3. How complex does the project NEED to be? The rule of thumb is - as simple as it can possibly be and no simpler.

If you’re looking for a list of frameworks, I suggest the link provided at the top of this post.

Well, you say… What does THAT mean? And why the hype over Ruby on Rails or Stripes?

Convention Over Configuration is a fancy way of saying “Sensible Defaults.” (er… in my opinion.) You see, a framework is like your mom. Helpful, useful and inserts itself whenever it can. Sometimes you wish you could tweak it a bit, but no one wants to really completely dismantle it and start over. Personally I have never wanted to dismantle my mother, but that’s another blog entirely.

Whether a developer is working with .NET, Perl, ColdFusion or Java; configuration can sometimes be a problem.

When someone chooses a technology or framework for their project, certain restrictions are immediately imposed upon them, their design and the long term outcome of the project itself. This is the caveat of not reinventing the wheel. It’s not a bad trade off at all, and the payoff can be wonderful. However, when anyone implements a “framework” they are agreeing to comply with the framework’s needs. If a person uses Hibernate (or NHibernate for you .NET folks,) they must configure it! The same is true for Spring, Struts, etc. These frameworks are all good at their jobs when used correctly but… one must tell them how to behave.

For the uninitiated, let’s clear something up. A framework is NOT a library. They are two vastly different things. What’s the difference? A framework inserts its behavior into your application and can provide external control with which you must cooperate. A library is simply used. They are on opposite sides of the coin of control. There are two basic kinds of application frameworks. There are blackbox frameworks and whitebox frameworks

So, that said - frameworks require configuration. This is sometimes a LOT of work, and it is also a lot of work to come behind a developer and try to figure out why a particular page navigates this way or that, and where the heck is that configured anyway??

That is the problem “convention” tries to solve. Put simply, when you’re adhering to a conventional means of doing something, you can make a LOT of assumptions and be right. Someone can then come behind you to do some maintenance work and make some assumptions and also be right. This saves time. With frameworks like Ruby on Rails or Stripes, a person simply has to name things the right way, and the application is magically wired together. However, there is a trade off.

Any convenience that a framework (or Operating System for that matter,) provides, usually comes at the price of the loss of control at a low level. The more any entity does for you, whether it be your mom, your government, your operating system or your framework of choice, you lose a little bit of control (or sometimes a lot.) However, managers and CIOs and developers too, are tired of the ability to easily make mistakes. They are also tired of having to train people to use a framework. A framework should save the company money, and be easy to work with.

To say a framework is easy to work with is a subjective statement. However we could make that statement more quantitative by saying that a framework takes a certain percentage of time to piece together components, and a certain percentage of time to implement those components. If that is our measure of ease, “convention over configuration” is easier. These frameworks may not suit every application’s needs, so avoid the knee jerk reaction of “this will make our lives easier, let’s use it!!” That’s simply wrong. However, if an Application Architect really understands the business needs of an application and can use such a framework, most people believe that much time and money would be saved. That is why convention over configuration is exciting. Not because it’s fun, not because it’s new. It’s exciting because it’s marketable to management, and can provide quick results - especially in an Agile environment.