Sergey Nivens - Fotolia
Could someone please provide a proper toString() method implementation?
Why is it that twenty years after the release of Java, the lapidary toString() method still spits out nothing more than a useless hashcode?
One day, there will be a full increment release of Java, and when that two-point-oh version becomes official, I am desperately hoping they will include a fully implemented toString() method in the distribution. The toString() method has always been a annoyance to me, equivalent to that annoying little stone in your sock that mocks you on each and every step, but isn't significant enough for you to do anything about. That's what the toString() method is to me. Could someone please do something about it?
The entire point of the toString() method is to describe the current state of an object. The purpose is to provide a text based representation of the Person instance, the Account instance, the Transaction instance or whatever type of instance you have in your problem domain. When you are troubleshooting, or logging, or debugging an application, the toString() method is of ubiquitous use.
Maybe we should all just switch to Ruby?
So what's the problem? Well, the problem is the implementation in the standard distribution is paltry. If you're working in Ruby, and you ask for a String representation of an instance, you get a massive amount of information. Actually, let me rephrase that. With Ruby, you get an pertinent amount of information. When asked to provide a String representation of an object, the Ruby runtime takes a look at the instance, takes a look at all of the properties that the instance has, and then prints out the values assigned to those properties. It makes sense, right? And what does the Java runtime provide? It provides a pathetic hashcode.
Yeah, that's it. When you ask a standard Java instance to describe itself in text, it just blurts out some gobbledygook like @5A2J1C. That's not very descriptive, and it certainly provides limited troubleshooting and debugging capabilities.
Back in my teaching days, the toString() method was always one of the first methods to which students learning Java would be introduced. It was sold to them just as the JavaDoc sells it to developers, as a way to receive a text based representation of an instance. And when students enthusiastically invoked it, they disappointingly received hashcode nonsense in return. The obvious question students would ask was why the JVM didn't do the obvious thing and spit out the values of all of the instance's top level properties? Plenty of different answers might be provided, but regardless of the defense, students just walked away thinking the whole mess was stupid. Their instructor quietly agreed.
Misused and abused
The other ongoing annoyance is how the toString() method gets misused in development. At the onset of a project, someone might implement a nice, handsome, toString() method, but soon after, new properties are added to the class or old ones are removed. That means debugging and logging statements end up containing inaccurate data, or start spitting out a bunch of null vales. Again, it's a problem solved by right-clicking on the source code in Eclipse and choosing Source >> Generate toString() method. It's not an insurmountable challenge, but neither is removing that little stone that's stuck in your sock. It doesn't make the whole process any less annoying.
And if the toString() method isn't out of date, it's typically hijacked. Some developer has put their own snippet of code in there to simplify their troubleshooting. There's some descriptive text along with the values of some properties, and while you know that a good governance model or a thorough code review would have stopped that in its tracks, you still don't want to override it, lest you mess up the debugging cycle of your fellow programmer.
All of these little annoyances can be easily addressed. Simply have the handsome people who develop the roadmap of the Java language make a note that in some future distribution, research will be done and technology will developed to so that a JavaBean can introspect itself and print out the values of all of its top level properties when an un-overridden toString() method is invoked. Really, it's not that much to ask.
