Bikes and Code

Most of what I’m going to ramble about here was covered much more eloquently and in far greater depth in Beyond Java. These are my personal feelings and anecdotes on Java and it’s history. I should also note that despite what appears to be a moderately negative tone, I still do use Java extensively and used it to build the product of the rather short lived startup I co-founded.

I first encountered Java way back in 1998. This was effectively my first programming language, though I had done some C++ in high school. That wasn’t formally, mostly self taught and pretty much purely due to laziness. At one of the computer shows in Vancouver, (which might have been Comdex, did that show travel around?) I talked my father into buying me a C++ compiler and toolchain. It was definitely Borland, I’m fairly certain it was one of the Turbo C++ packages, though I have no idea which version now. Regardless, my main goals were to ease my physics and math homework by writing programs to do various tedious calculations for me. That was more or less a success, I still recall the joy at punching 3 numbers in and getting the solutions to the quadratic equation back. I learned about loops, variables and if statements, but nothing else really. But I digress.

At Carleton University, the first programming course I took was in Java, at this point in time, we’re talking Java 1.1 for the most part, the entire API was a couple of hundred classes at most. Supposedly it was kind of exciting because it was object oriented, but that was way beyond me for at least a semester. Mostly what I recall from my entrance to the world of programming was my epic battles with the compiler. I hated javac. There was perfectly valid… things in my file, at least as far I could tell, but javac would tell me that in no uncertain terms that I could not go so far as to call that text ‘code’. Eventually, the program compiled and joy was felt throughout the lands. Immediately thereafter, I would run the program, which would crash with a NullPointerException or some other fun error case. This was before the time of decent debuggers, at least to a novice programmer, so with a liberal smattering of System.out.printlns, eventually I could figure out where I had a mistake. Then change the code, fight with the compiler and the scenario would repeat itself until I could run the test cases provided in the assignment.

All in all, though, Java in those early days was a pretty simple language. You would make an array, do stuff with it and be happy about it. Or, once you started to grok how this object oriented stuff worked, you’d make a Vector and stuff things inside of it and you would never worry about resizing the array again. I mean, there wasn’t much to the language, check out the 1.1.1 API I just googled for. There were a couple of weird features for a novice to see, anonymous inner classes are a great example, it took me years to really understand how to effectively use those things.

Java 1.2 was introduced in December of my first year and included a number of things, the only ones that actually mattered to me as a fledgling programmer was Swing and the Collections library. Swing because the winter term had a Java graphical user interface (GUI) course and the collections library because I could now cheat and use LinkedList instead of always having to write my own for each assignment. Maybe it wasn’t every assignment, it just seemed that way, still.

Java 1.3 did not really add anything of use to me and stayed out of my awareness. Java 1.4 added a few more things and I wrote a fair bit of code with that version. Still though, Java was still the same old Java as I had used back when I started with it. There were new libraries, and that was nice, Java was growing with me as I needed to do more with it. There wasn’t any real new syntax that had to be learned, if you hadn’t seen regular expressions before, it was a bit of a shock to see Perlish things in Java 1.4 but for those of us who had used them, it was nice to have the power of regular expressions in Java.

By this time I was working in the industry, specifically on a rather interesting Java application that was officially using 1.3 Java when I first showed up on the scene, 1.4 shortly after I started writing code for it. I should  note that I mean interesting in terms of the curse, “May you live in interesting times”. Not as in, “That book is great, some really interesting points.” The system was the definitive legacy but business critical application, so arbitrarily going to a new Java version wasn’t going to happen until the powers that be had given it the official green light. At the time I was happily drinking the generics kool-aid, helped in no small part by the .NET team at the company who was gushing about how much the .NET generics implementation had helped them. I pushed for the migration and eventually we had migrated to a 1.5 JVM and all was good.

I learned the new syntax for the generics and for a while it was great, but a few things were beginning to bug me. In the entire time I had worked at this company, I hadn’t actually seen a ClassCastException in the wild. This appeared to be the main thing that the generics were attempting to fix. The syntax was a bit clumsy and fairly verbose, especially if you had descriptive class names. Making a generic class was an exercise in pain. Enough so that after one serious attempt, I nixed it in favour of a single purpose class that could only take instances of a given interface. Most grievous in my mind was that after going through all of this anguish to get a generic class, as soon as you hit run time, you could not use reflection to actually figure out what *should* be in the container. I remember being shocked when I found this out and needing a coffee break to reassess.

From what I could tell, all of this extra syntax was being entirely tossed out before run time, which meant all that extra typing and ‘safety’ was a merely a compile time check. One of the first lessons learned in programming was that just because something compiles does not mean it works. So while getting a bit of extra information at compile time is nice, I couldn’t help but think the benefits of the check was not worth the cost of the extra time spent typing and managing the syntax. (Side note, no, it’s not ‘just typing’, it is the most fundamental skill a programmer needs to have and should be taken very seriously. Arguments here and here.)

Regardless, I soldiered on and slowly encountered other 1.5 enhancements that made Java more complex. Annotations, which through a new syntax would allow you to add some extra meaning to a method, class or variable. Enumerations, which I do love using when the previous option was lists of static final integers or strings. That however, was done with a new keyword, ‘enum’, which by some entertaining coincidence was the exact variable name used throughout our codebase for Enumerations. (Enumeration enum = hash.keys(); Eventually I will write more on code quality in that entertaining project.) Never mind the fact that now you have to talk about Enumerations or enumerations, which is always entertaining. Then there is the varargs syntax, which just feels like a solution in search of a very specific problem. Seriously, I mean, have you ever needed this? Then there is autoboxing, a nice feature, but blurs the lines between objects and the Java primitive types, which can lead to a whole new way for developers to misunderstand what a block of code is doing.

I no longer feel that Java is a good language for a new developer to start programming in. It has it’s advantages, but those are almost exclusively in the domain of large ‘enterprise’ systems now. Some of the changes appear to have been to keep maintenance costs down and to mitigate the damage a low quality programmer can do. Some of the changes appear to have been good ideas, but they were done at the cost of making the syntax more complex and complexity is the enemy of software development.

The object-relational impedance mismatch. Unquestionably one of the stickier problems that a developer working with a database backed system has to deal with today. Depending on exactly who you believe, it’s fairly safe to say that a significant percentage of developers have encountered this particular problem. I won’t go into extreme detail on the problem as this article covers the main points beautifully. I will give a brief outline of the problem, then discuss my thoughts on Hibernate and Ruby on Rails, two technologies which address some of the problems. Neither is perfect, but they both have merits.

Most software developed today is object oriented (OO). This isn’t news to anyone, it makes a developer’s life easier as it allows you to conveniently forget about big chunks of code, which means you can hold more of the system in your head at once. This is good all around. At the same time, a sizable percentage of development efforts store their data in a relational database. Databases allow someone working on a software project to ignore the issues of storing and retrieving data. Thus, in many of these projects, the world of objects meets the world of relational databases and that causes problems.

One of the ‘solutions’ to the problem, quoted as they only address the actual software development aspect of the equation and not the political or infrastructural aspects, is Object-Relational Mapping (ORM) software. ORM software tries to take an object model and map it to a relational database or vice versa, depending on the system. The idea behind ORM is that if you manage to intelligently write something that maps from one to the other, you can keep your database and OO software distinct without having to deal with the messy logic that is required to go from one to another.

What I’m getting into here is more the ‘feel’ of the frameworks in question I am not passing judgement on either one as both of these frameworks provide significant benefits and drawbacks.  I’ve used both of these a fair bit in recent months and while by no means an expert, I can at least appreciate what they are trying to do. I should also note that there are likely errors, I am certainly overlooking aspects of Hibernate, my defence to that is poor, mainly that the framework is just too huge and knowing it all is at least a year long full time project. Few people other than full time Hibernate developers can afford that kind of investment.

If I had to use a single sentence to describe how a developer should approach the Hibernate framework, it would be, “The object model is god.” Hibernate is geared around using XML or annotations (what I actually used primarily) to mark up the object oriented Java code with hints, pointers and information on how an object should be written into the database. In practice, this means that in many cases until you actually go into production where other people start relying on the data, you may not even need to think about the database on anything more than a trivial level. You write your Java, add the hibernate hooks and let the framework do the rest.

With the ActiveRecord aspect of the Ruby on Rails framework, the equivalent statement would be, “The database is god.” In Rails, you create your database, set up all of the tables in some normalized fashion, following a naming convention and walk away. Rails then analyzes the actual database and generates objects which you then use in your application. You need to provide hints to the system when you start working with actual concrete relationships, but in general Rails does a decent job of generating objects which let you save and retrieve data.

I suppose it should not be a surprise that the Java based framework takes the approach that the objects are the key to the system and the database is a pesky, but important aspect that needs to be managed. Rails, a framework which is possibly THE case study in pragmatic programming, on the other hand, simply re-writes itself to match the database. Put another way, the feel I get from Hibernate is, “Write good OO code and we can map it onto a database.”  Rails, on the other hand appears to be simpler, “Well, you’re stuck with that database, here are the objects to manipulate it.”

The unsaid downside to Hibernate and the one problem I have with it is that you can go a long ways towards avoiding SQL and thinking directly about the database, until you need to refactor your code. Refactoring your code will likely mean needing to refactor the database to match your changes and in many organizations, this is simply not possible due to political reasons. (Accounting and sales have their own systems which use your data! You’ll break them if you change!)  At this point, SQL will start creeping into your code, while not a bad thing in and of itself, SQL that makes it into the system does start to mitigate the benefits of a full ORM system. Of course, this problem could be minimized by keeping an array of objects that do have accurate mappings and then putting an abstraction layer on top of that to massage the Hibernate equipped objects into actual system objects.

This is not to say that refactoring a Rails application would not end up with the same problems, however, your Rails code, by virtue of being generated from the database and not from the objects means that you have some sort of stability in terms of having a layer that does accurately map to the database, whether you like it or not.

The opposite approach that these two frameworks take is fairly interesting, especially when you work with them back to back. My gut feeling is that, all other things being equal which I should stress they are not right now, over the long term the Rails approach is going to be the more maintainable of the two. Unfortunately, for the foreseeable future, Rails simply will not be an option for political and business reasons, some valid, some not. (Valid: More good Java developers than Ruby developers right now. Not Valid: Scalability arguments, very, very few applications need to scale to millions of concurrent users, so for most of us, this isn’t even a concern.)

Anyhow, that’s it for now, it’s been on my mind for a while.

I have returned to the world of blogging. Whether or not this is a good thing remains to be seen. Granted, my first crack at the activity was more of a way to avoid massive numbers of emails  as I cycled across Canada with my then fiancé. Inspired by both Steve Yegge and Jeff Atwood, I think I’ll give this whole on-line writing thing another shot. Recently they have both publicly stated, or more accurately reiterated, that having an on-line persona is probably fairly important if you think that someone might google you at some point…

Regardless, in the spirit of these things, an introduction.

I currently live in Ottawa, Ontario with my wife and two budgies. I am what I consider to be a professional software developer. I have been working with Java on and off since 1998 and that is currently my most comfortable language. That said, I am currently enjoying Ruby quite a bit. I use PHP for general scripting needs. I have also written a couple of not totally trivial applications in C++, though that was a while back now, and at least recognize Lisp. In previous years I have also tinkered with 3D engines and OpenGL programming.

Recently I have worked (re-) writing an on-line store framework for a printing company using a Java/JSP based approach. I more or less headed the re-write effort and over the course of a couple of years had replaced the entire code base while shrinking it from 140k lines of code down to about 70k. There will be blog posts on the awesomeness of that project in the future. Following there, I became the lead developer and co-founder of a short lived start-up. It didn’t make it (officially as of late last week, but in hindsight, I should have known a couple of weeks before that), but mostly due to the mistakes of the founders more than anything else. Next time, I will more closely heed Paul Graham.The software was written in Java and used the Google Web Toolkit (GWT) extensively. Enough so that I can feel that I can comment fairly intelligently on the pros and cons of that framework. I intend on releasing the application with an open source license eventually, but when exactly the right time for that is currently debatable.

That about covers the ‘code’ portion.  I also like to ride bicycles. Mostly this is for fitness purposes, but I also dabble in racing. Dabble is a key word as I am terrible (== slow) at it. Right now I am about halfway through the cyclocross season here in Ottawa. The local Ottawa Bicycle Club puts on a most awesome series, you can find me at the bottom of the various R2 results at www.cyclocross.org.

That about sums it up, I’m aiming for something twice per week or so, that should be one cycling and one code relating post. We shall see.