Method Pointers

[Brian Goetz]

We're getting pretty far afield here from lambda, but it is most 
certainly not a language feature.  The intent was never to be able to 
compare strings with ==.  (How could users know that the other string 
came from a literal?)

Perhaps your confusion is one of terminology?  The fact that some part 
of the *platform* specifies a behavior does not mean that it is a 
language feature.

On 3/26/2012 2:39 AM, Peter Levart wrote:
> On Sunday, March 25, 2012 06:37:00 PM Brian Goetz wrote:
>
>  > > OK, so this is simply an implementation hack, which happens to improve
>
>  > > performance, and has the side effect of probably confusing new users,
>
>  > > rather than a deliberate, unreliable design feature?
>
>  >
>
>  > Which is almost identical to something we do in javac -- fold together
>
>  > identical string literals within a class into the same constant pool
>
>  > entry, resulting in strings appearing to be == accidentally.
>
> I allways thought this was a feature not an accidential consequence.
> It's written down in the String's javadoc as:
>
> "All literal strings and string-valued constant expressions are
> interned. String literals are defined in §3.10.5 of the Java Language
> Specification <http://java.sun.com/docs/books/jls/html/>"
>
> So perhaps we are talking about two different things here:
>
> 1) identical strings in the same class are folded into the same constant
> pool entry (as optimization of class file size)
>
> 2) string literals are interned (as a language/library feature)
>
> The fact that identical literal strings apear to be == is therefore a
> language feature, not an optimization side-consequence.
>
> Peter
>
>  > We don't
>
>  > do it to confuse the users, but it may have that effect anyway.
>