[B][Stefan]:
would have been a more readable name, and would fit to all Classes, I guess.[/B]
Have you looked at the other wrapper classes, like Integer? They all have parseXXX() methods - but those methods always return the corresponding
primitive value, not a wrapper object. There are also valueOfXXX() methods which return wrapper objects rather than primitives. So if we wanted a method in Boolean that returned a Boolean from parsing a String, the logical name for such a method (based on well-established
patterns) would be Boolean.valueOf(String). Which, coincidentally, is in fact a method in the Boolean class. Convenient, no?
As for getBoolean(), I agree it's an embarrassingly bad name for the method. I'm guessing someone named it that way back somewhere in JDK 1.0, and now Sun doesn't want to break backward compatibility for the few poor souls who are using the method. :roll: I would suggest that the method
should have been in the System class, next to getProperty(). A good name would have been getBooleanProperty() or maybe getPropertyAsBoolean(). Oh well.
Jeff: String's toString() method is actually useful. What should happen if toString() is called on a String? The default implementation of toString() in Object would return something like
java.lang.String@7d772e
Is that a good representation of a String? Since it is, in fact, a String, why not return itself? That's why toString() is defined in String - to override Object's default implementation.
You may be wondering why anyone would ever call toString() if they already have a String. But remember, you may be in a context where you don't yet know what kind of object you have, but you want to print its value anyway. Remember that you may implicitly call toString() on an object just by putting a + next to it (provided there's another String on the other side) - so it's easy to call toString() on an object without realizing it. String's toString() is just there to provide slightly more sensible behavior in case that happens.