Rationale for "Please use string literals to identify properties."

[Sigfried]

Hi,
in javadoc of "javax.swing.table.TableColumn.COLUMN_WIDTH_PROPERTY",
there is this sentence "Please use string literals to identify
properties.". Could you explain what is the ratonale for that, plz ?

 

[Andreas Leitgeb]

Perhaps, they just didn't see any other way out once the typo ("columWidth")
slipped through. ;-)

 

[Sigfried]

Peter Duniho a écrit :

Just looking at the docs, and Google (Google can be very useful...you
might have heard of it ), it looks to me as though this was the
string you used to look for when listening for property changes on the
TableColumn class (see addPropertyChangeListener()). But now they say
to just use a string literal for the name of the actual property you're
interested (e.g. "width").

I understand the sentence, i was asking for a reason, a rationale...

This specific constant has a typo in it, but others (in TableColumn
especialy) have the same advice. Is there a good reason for that ?

 

[blue indigo]

Or if the string literal itself is where the typo is, perhaps it's as
Andreas suggests: Sun realized that it's better to just have the API
respond to names already documented elsewhere, rather than providing a
separate constant that has to match (and thus offering an opportunity for
it to be wrong).

Isn't the normal and best-practise thing to do here to use the same
constant where the code reads strings looking for a match as in the code
that passes that code a string?


public void accept (String s) {
if (!s.equals("foo")) throw new IllegalArgumentException();
}

public void test () {
accept("bar");
}

compiles but fails at run-time; and as you noted,


public static final String THE_STRING = "bar"

public void accept (String s) {
if (!s.equals("foo")) throw new IllegalArgumentException();
}

public void test () {
accept(THE_STRING);
}

fails at run-time because THE_STRING has gotten out of synch with the
literal in "accept". But


public static final String THE_STRING = "bar"

public void accept (String s) {
if (!s.equals(THE_STRING)) throw new IllegalArgumentException();
}

public void test () {
accept(THE_STRING);
}

succeeds, and


public static final String THE_STRING = "bar"

public void accept (String s) {
if (!s.equals(THE_STRONG)) throw new IllegalArgumentException();
}

public void test () {
accept(THE_STRUNG);
}

fails at compile time (at both mismatches).

 

[Lew]

Isn't the normal and best-practise thing to do here to use the same
constant where the code reads strings looking for a match as in the code
that passes that code a string?

That'd be why the OP asked,

Could you explain what is the ratonale for [using literal Strings], plz [sic]?

 

[Lew]

Isn't the normal and best-practise thing to do here to use the same
constant where the code reads strings looking for a match as in the code
that passes that code a string?

Second-best practice. The best practice nowadays is to use an enum.

 

[blue indigo]

Second-best practice. The best practice nowadays is to use an enum.

Even as a key in a .properties? ;-)

 

[Lew]

Even as a key in a .properties? ;-)

Actually, yes, IMHO. (Though, naturally and easily-inferrably, via a
'toString()' conversion.) Type safety at compile time is worth the slight
extra effort.

That seemed like a serious question. Why the winkey?