JCK feedback on "Strings in Switch" proposal

[Ulf Zibis]

>> I think it would be better to define "expression == constant" for 
>> several reasons.
>> (1) "switch..case" syntax historically is expected to be very fast. 
>> See discussions on:
>>    http://forums.java.net/jive/message.jspa?messageID=4146#4146
>>    http://forums.java.net/jive/message.jspa?messageID=14216#14216
>>    http://forums.java.net/jive/thread.jspa?threadID=504
>> (2) Comparison for identity would better match to legacy semantics of 
>> "switch..case" statement.
>
> No, it would not.  Comparing strings for "==" equality is a common 
> programming error so the semantics of strings in switch should be 
> defined in terms of .equals equality.

I think, I got your opinion.
Variables are equal, if the values of their chunk of bits are identical 
(not generally, but in case of primitives and String objects).
Variables are identical, if the memory location of their chunk of bits 
is the same. So primitive variables are never identical, as their chunk 
of bits are stored in different memory locations, and pedantically 
argued, "i == j" (for primitives) is always false, they should be 
compared by "i.equals(j)". Theoretically we could define "==" as 
comparison method for the switch..case construct, and accept the upper 
imprecision as legal for primitives. If the programmer wants comparison 
by equals(), he should explicitly write the syntax for it, e.g. in the 
way, I have proposed in my "switch for objects and expressions"-proposal.

Having this, comparing by "==" can be seen as a programmatically 
shortcut for "equals()" in case of interned String objects (Literals are 
automatically interned by definition).

There are 3 interesting, widely used types of comparison of Strings:
- s1 == s1
- s2.equals(s2)
- s2.equalsIgnoreCase(s2)

The first 2 are covered by the given "Strings in Switch" proposal.
IMHO we should not abandon the attempt to provide a smart syntax for the 
3rd type of comparison in case of Strings, and even similar for general 
objects.
if..else constructs seem not to be smart.

-Ulf