greggwon at gmail.com
Mon Mar 26 07:04:45 PDT 2012
On 3/26/2012 8:20 AM, Brian Goetz wrote:
> 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.
It's important to understand that perhaps 60% or more of the "programmer"
population have no "software engineering" training and have no idea what
"platform", "language specification", or other terminology means. If it happens
consistently, and/or there is written information somewhere that says it will
happen repeatedly, then it is a "feature".
This is the world we live in now that the Web Craze has brought far too many
"programmers" into the fray without training, because they were "cheaper", and
they were "motivated to learn" (they could earn money). And, their managers and
employers have just as little knowledge of what software engineering is really
> 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
>> 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.
>> > We don't
>> > do it to confuse the users, but it may have that effect anyway.
More information about the lambda-dev