Parsing booleans: a new-fangled invention
April 16, 2008I’ve made an effort when writing Biff to keep it compatible all the way back to Java 1.4.2. A lot of people still have this old version installed, since it was so popular back in its day (also, GTGE is 1.4.2 compatible, so I thought I’d stick with the engine). I’m running 1.6, but I’m quite aware that not everyone is.
For the most part, this means no enums and a lot of casting objects stored in Vectors. A lack of enum is a bit silly (from the beginning, if you ask me), but can be worked around. And Vectors don’t get used a whole lot, so overall I haven’t regarded this as a big deal.
Take, however, these two extremely similar methods: Integer.parseInt() and Boolean.parseBoolean(). They each take a String and return the equivalent primitive. Obviously very handy when you’re reading sprite data files or whatever as text and you want actual values.
parseInt() has been around forever, and I’ve used it many times, so I was not surprised to find an equivalent in the Boolean class. Except I just noticed that parseBoolean() has only been included since Java 1.5. Why it hasn’t been there from the beginning, I don’t know. Did Sun think that integers are the only values that might occasionally be stored as strings?
The dumb thing, of course, is that as a result Biff needs Java 1.5 to run, despite my attempts to the contrary. And the thing gumming up the works is, of all things, parsing a text file.
You can use something like this under 1.4:
boolean var = Boolean.getBoolean(str.trim());
That’ll look for the word true, case insensitive. That’s only looking for alphabetic boolean though, no ints/nulls/etc.
Having your source level at 1.5 isn’t that big of a deal though. I’m doing my Java 5 certification right now and the jump from 1.4.2 to 1.5 is massive. Filled countless gaps and makes the whole language much better to work with. After using generics and auto-boxing/unboxing, it’s pretty hard to go back.