In December 2011, the Hibernate team announced the release of Hibernate 4.0.Final. A year and a third later, it seems like Hibernate 4.x is still not as mature as I would have liked it to be on launch, let alone with all this extra time to add finesse. This makes me question the viability of the 4.0 line whether or not there are deeper problems with the project and team that are visible on the surface.

Project Background
A client of mine has a project that is now almost four years in development (over multiple releases, of course), and that started with Hibernate 3.3.x, which was current at the time.

During a number of those releases, the project team considered updates on various dependencies, including Hibernate, but hadn't found a compelling reason to upgrade. Since any upgrade introduces some change and risk, this project has continued to use 3.3.x.

A bug filed against that project recently showed that Hibernate's handling of character database columns (e.g. CHAR(10)) was somewhat flawed. This defect is fixed in Hibernate 3.6.8 and Hibernate 4.0.0.CR5, so it was time to evaluate Hibernate for an upgrade.

Evaluating Hibernate 4.x
Since Hibernate 4.x had been out for over a year, it seemed like it was probably worth serious consideration as the target version for the upgrade. I discarded 4.2.0.Final because it was relatively recent, and did a trial upgrade to 4.1.11.Final. The 4.1 line has been around since early February 2012, so it is also more than a year old.

There were immediately some issues, which I expected -- APIs have changed, deprecated methods removed, and so forth. This is pretty normal for an upgrade. But over the course of solving those problems, I got the strong impression that Hibernate 4.x still hasn't matured. After fighting with that for a while, I eventually decided that I would drop down to 3.6.10.Final, which is where I left it.

JDBC Connection and Work API
One of the first stumbling blocks was the removal of the deprecated method to get the JDBC connection underlying the Hibernate session. There are a few places where this project interacts directly with JDBC, because it's the best fit for that particular situation, and rather than having two mechanisms for accessing the database, we borrow Hibernate's JDBC connection to do a little bit of work.

Hibernate has allowed you to access the underlying JDBC connection for a long time, but in Hibernate 3.3.0 (I believe), this methods was deprecated and a new API where a connection is passed into a custom class implementing org.hibernate.jdbc.Work was introduced. This allows Hibernate to manage the JDBC connection more directly, which seems like a sensible idea.

In Hibernate 4.x, the deprecated Session.connection() method was removed. I'm in favour of removing deprecated methods, so this didn't bother me, and I set about modifying the project code to factor this in. It added some awkward indirection in our existing approaches, but I could see that a more involved refactoring might make that less awkward.

However, I also discovered that the Work API isn't covered in the Hibernate documentation (it's only even mentioned once that I can find), which still refers to Session.connection (e.g. Developer Guide, Reference Documentation), which has already been removed.

When Hibernate 4.x was first released, referring to methods that have been removed in the documentation would have just been an oversight. Over a year later, it seems clear that this isn't something that's just about to be fixed.

Bootstrapping Hibernate
For the longest time, bootstrapping Hibernate went a little like this:

  Configuration.configure().buildSessionFactory();

Hibernate 4.x involved a significant change the plumbing of Hibernate. The release notes mention both "Clean up of Session opening from SessionFactory" and "Introduction of ServiceRegistry". In the process, they deprecated buildSessionFactory() in favour of buildSessionFactory(ServiceRegistry). Wanting to better understand this change and learn the proper replacement for the above stanza, I went to the documentation.

Unfortunately, here's another case where the documentation is out-of-date, continuing to refer to now-deprecated initialization approach: Getting Started, Reference Manual. In looking at the source code comments for Configuration, I found references to Jira issues talking about deprecation (and that Configuration would be removed in Hibernate 5.0): HHH-6183, HHH-2578 and HHH-6586. Reading these and some related issues implies that the hibernate team:

• Intended to deprecate Configuration during this architectural shift to redesign session factory building, starting with buildSessionFactory().
• Didn't update the documentation to describe the preferred new approach.
• May not even have a working new approach (e.g. see comments on HH-6617)
• Decided some elements of their revisions are experimental and unsupported.
• May remove the deprecation from Configuration in the meantime.
• Will eventually remove Configuration, although one hopes they'll sort this current mess out first.

On a recent project, my client needed a small web application to be developed in ‘pure JSP’ for a client of theirs.[1] In essence, their only route to deploy anything in the production environment was to commit it to a subversion repository which would later get deployed on their behalf. This made anything but the simplest deployments tricky. Adding frameworks to the project or deploying precompiled code was only going to cause problems.

If you haven’t done much web development in Java, this might not sound particularly unusual. Deploying a php, rails or python project typically doesn’t require much in the way of compilation, and while framework are common to both, doing without wouldn’t be a particular stumbling block.

For a Java project, this is fairly unusual – a classic Java web project uses the MVC pattern and establishes a fairly strict separation between the model, view and controller where the model is plain Java, the controller is a Java servlet, and the view is JSP:


There are lots of alternatives[2] depending on your preferences and technology choices, but I haven’t seen many Java projects implemented using only JSP.

Writing a Pure JSP project would rule out using Java classes[3] for the model and controller, and limit you to whatever you can accomplish in a JSP. Having said that, I couldn’t see any fundamental obstacles to building a project in pure JSP, I just hadn’t done it or seen it done. I did few quick google searches and didn’t see many people suggesting this approach, so I decided to conduct a quick exploratory spike.
After a little testing, I quickly found that there were at least two choices that would work, which I’ll call “JSP Controller” and “Embedded Controller”.

JSP Controller

In this style, you simply replace the controller servlet with a JSP page that acts like a controller servlet. JSP pages are essentially Java servlets in a different form, and if you write a JSP page that contains no HTML or CSS, but instead parses the request from the browser, does any necessary processing and then renders the response using another JSP page, then you have what amounts to a controller written in JSP:


Of course, if you’re avoiding precompiled Java classes, you still can’t use an external Java-based model, but you can use the standard Java class library, as well as inner classes. This isn’t the cleanest way to model your domain, but it’s enough to get by.

Embedded Controller

If your control logic is pretty simple, you might simply embed the control logic in the view up-front. This mixes the view and controller in a way that some might find unpalatable, and a little retro[4], but it does simplify things a little and makes it a little easier to share model code with inner classes. This is the simplest approach, but also the one most likely to make an unmaintainable mess if your project will be growing:


This client project was a very tightly-scoped piece of functionality, so I used Embedded Controller and was reasonably happy with the end result, all things considered.

When to use Pure JSP

I’m not advocating for Pure JSP projects as a generalized solution to web development in Java. It adds a lot of constraints to your development style for benefits that are of limited value in most projects.

But if you need to build a small project that will run in a Java-based environment and you don’t have a lot of access to the production server or detailed knowledge about how it is configured, these approaches do simplify things.

By writing this up, I hope to save some of you a similar exploration; if you’re in this position, you’ll know this is a path that others have taken and that it all worked out in the end.

A client of mine, Canada Protection Plan, is looking to hire a Software Developer here in Toronto.

Canada Protection Plan: Software Developer

Canada Protection Plan (CPP) is the leading provider of non-medical life insurance in Canada. We're growing rapidly and we're investing in software to help us grow our business further.

We've built web-based system in Java and Google Web Toolkit (GWT) for entering and managing insurance applications which is used throughout the company daily by many of its employees. Although it's already a successful project, enhancements, new features and entirely new opportunities for this system are in heavy demand.

We're also starting a new system for managing our in-bound call centre and customer contacts, integrating with our telephone system, and tying customer response to marketing campaigns to automatically gauge their effectiveness.

We have an existing team of full-time employees and software consultants, but we need to continue to expand the team to meet the growing demand for software and technology.

We are currently looking for an intelligent Java developer who is able to take ownership of tasks independently as well as work in a group setting. The ideal candidate will know of and be guided by good programming principles, but is not afraid to think outside the box.

If you're the sort of developer we're looking for, then you're a hands-on software developer with experience across the whole spectrum of building software, capable of laying out a user interface, turning business requirements into well-tested software, modeling and building object and data models, familiar with web development, software services and databases.

You'd be joining the team as a full-time employee and help us to enhance our existing systems and build new systems using Java, GWT, server-side services, MySQL databases. You'd help build maintain the development and operational environment using Linux, Tomcat, MySQL, Maven, Pivotal Tracker, Eclipse, TeamCity and Subversion as well as system monitoring and operations. You'd even occasionally help troubleshoot some technology issues around the company.

You should be capable of working well within an established team using agile methods and also independent and self-directed so that you can take on tasks or small projects by yourself if need be. You'll be working with our existing team of software developers as well as working directly with the business teams, the employees and managers who will be using the software you create.

If you have extensive knowledge of Google Web Toolkit, or of the life insurance industry, make sure you call that to our attention. That said, we believe that anyone with a broad-based understanding of web development and of Java should have no trouble picking up the specifics, so there are very few hard technology requirements. Intelligence, desire to learn and passion speak volumes about what you can accomplish.

This position is well-suited to a developer with some experience who is looking to learn by diving in and working with a strong team of senior-level developers and take on additional responsibilities as the company and the team continue to grow. It's an opportunity to be involved with a fun and great team at a company that's growing quickly.

If you're heavily specialized and you prefer working on a very large development team with clearly defined roles and limited responsibility, never interacting with your users, you'll probably hate it here. This is a role for someone who likes to build end-to-end systems, take on whatever responsibilities are available and work hand-in-hand with the business team.

CPP is located at Eglinton and the Don Valley Parkway:


View Larger Map

There's a convenient shuttle-bus from the Yonge subway line, easy access via the DVP if you're driving, and a few different TTC routes.  Our office has nice views of the surroundings, a spacious company café, parking and there's a commercial fitness centre and two restaurants in the building.  We'd love to have you come by so that we can talk to you about the position and give you a tour of the office, so start by sending in your resume.