Java API Pitfalls: Boolean.getBoolean(String)
Creating a public API is a task that should not be taken lightly. Any bad decision at this stage tends to become baked in, remaining there for posterity. One such lousy decision was made by an unnamed Sun engineer, eons ago when dinosaurs roamed the earth and the Java programming language was born.
I can imagine this developer thinking to himself "I really need a method that gets a boolean value from the system properties. Since this method returns a boolean, it obviously belongs in the Boolean class! Now let me think, should I call it getBooleanSystemProperty? Nah, that's way too long and I don't have an IDE with code completion. I'll just call it getBoolean - it's so much catchier and saves typing fourteen characters!".
And thus, the Boolean.getBoolean(String) method was born.
Cut to a few years later, a programmer needs to convert a String to a boolean value. Remembering that there's some static method in the Boolean class for this, she types "Boolean." and waits for the code completion popup to appear. Her eyes scan the list of method names, and stop at getBoolean. "This is it" she thinks, failing to notice that further down the list there's also a method called valueOf.
A few weeks pass until somebody notices that no matter what string value the program receives, it always treats it as "false". It takes another few hours to trace the cause of this bug to the innocent-looking call to getBoolean.
Now you may think that this story is fictitious, but I've seen this mistake being made at least twice. And the fault lies entirely with this method, which is located in the wrong class and has a name that does not convey its purpose accurately. If you don't believe me, just ask Glen Stampoultzis.
What surprises me the most is that Sun didn't choose to deprecate this method, as a way of admitting that they screwed up and flagging that it should not be used. And so, it remains a part of the core Java API, like a landmine waiting quietly to be stepped on by a poor victim.