Strings…every application has/needs/uses them. I’m using Rational Application Developer, IBM’s IDE that runs up on top of Eclipse. It’s typical IBM software…big, a little slow and somewhat dependable (I believe that’s classified as a backhanded compliment).
Anyhow, RAD (as the cool people call it) has the standard Eclipse based SOURCE options. One being ‘Externalize Strings’. I’ve seen it on the menu a thousand times but never used it. That changed the other day. I had some spare time and some LDAP Attributes referenced from within the code. I highlighted the string “cn” and clicked “Externalize Strings”…biz…pop…bang, a Wizard pops up and presents me with a screen asking what I’d like to use for a key to reference the string (which, ironically enough…is a String). Smokes starts billowing from the exhaust vent, the drive grinds away and presto…a nice little class for grabbing a resource bundle (populated) for the string. My old reference to “cn”
String commonName = getAttribute("cn");
has been replaced with
String commonName = getAttribute(Messages.getString("TransAltaPumaProfile.cn");
so that’s that…mission accomplished, right?
I read an article recently that asked readers what they spend more time doing, reading software or writing it. You know what…the answer is pretty obvious. We read our code far more often than we write it. That’s my first issue with the output of “Externalize Strings”, it doesn’t read nicely. It takes the reader away from the context of their task. Yes you can name the Class for retrieving strings something more meaningful than Messages. A small gain. The Genericists (I believe I made that word up) will tell you not to be too specific with your message bundle…context lost.
That’s my first issue with it. My second, and more significant, issue is the potential for lost time in debugging a change to the ‘key’ string. Whether you like it or not, Java is a compiled language. There are benefits to living with a compiler. It’s loves to complain. If you accidentally (for those of us who make mistakes) change the “TransAltaPumaProfile.cn” to “TransAltaPumaProfile.cnm”, what does your compiler do? That’s right, nothing. It takes the “you want to play with dirty little strings, go for it…I won’t stop you until runtime…but when one of them comes into my room, to play with my stuff…it better be right” attitude. I thought about this and the first thing that came to mind was, “whoa…bad news…I better take those keys, the magic ingredient to the entire ordeal, and put them in an interface somewhere…really lock ’em down”
Yep, “File/New/Interfac….wait a second” what was I thinking? This was all to satisfy some frail bit of whiz bang provided by my IDE.
So here’s what I did. Wrote an abstract class with some public final static strings on them and referenced those in the code. Now, this line of code:
String commonName =getAttribute(Messages.getString("TransAltaPumaProfile.cn");
looks like this
String commonName = getAttribute(LDAPAttributes.COMMON_NAME);
If I accidentally (for those of us who make the occassional mistake) change “LDAPAttributes.COMMON_NAME” to “LDAPAttributes.COMMON_NAMES”, the compiler (Felix) tells me (Oscar) that I screwed up, that the referenced String doesn’t exist and that I need to seek professional help.
I also like this approach over an interface since I don’t need to declare the implementation of the interface in order to use the String. That’s always bugged me. There’s a certain pipeline application out there with a barrage of Strings held within interfaces. I won’t name names but someone had us do a lot of interface String work on that gig…likely an idea that came to him while out for a ‘jog’ (that’s right, I said jog).