10 Reasons We Need Java 3.0
Subject:   Fix String handling once and for all...
Date:   2004-01-14 10:42:34
From:   anonymous2
There's *no* good reason why Java programmers testing two Strings for equivalence should have to put up with abominations like:

if ((foo != null) && (foo.equals("bar"))) {}

I challenge anyone to think of a meaningful scenario when a Java programmer is EVER likely to care whether two Strings that render out to identical sequences of characters LITERALLY came from the same definition in the source code.

At the very least, the String class' equality methods should all have static variants that take two String objects as arguments and treat null & zero-length as "blank". For example...

if (String.equals(foo, "bar")) {}

if (String.equals(foo, null)) {}

if (String.equals(foo, "")) {}

The last two evaluating to true if foo's value is null OR blank, the first returning false if foo's value is anything besides "bar" INCLUDING null or blank.

I'd even go so far as to suggest that String (or at least StringBuffer) should have a constructor that takes a File object as its argument & decides how to handle it based upon the presence or absence of a BOM -- no BOM, use the default local encoding (most likely some variant of ISO-8859); BOM, sniff the unicode variant and go with it; null or nonexistent, return a blank string (if the user REALLY cared whether it's blank or null, he would have explicitly tested the File object anyway).

Alternatively, annoying things like UnsupportedEncodingException should be made unchecked. I mean, for god's sake, if "UTF-8" or the system default encoding should, through some catastrophe, EVER be unsupported, the program has FAR bigger problems to deal with. Make it extend RuntimeException, and programmers who need something more exotic like Shift-JIS or ISO-8859 with Scandinavian encoding that might actually fail can catch it.