Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <44564D2B.7060303@gmail.com>
Date: Mon, 01 May 2006 14:02:19 -0400
From: DM Smith <dmsmith555@gmail.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: this == that
References: <9B6D1255-6580-4DD8-9C83-D1C37B331F95@snigel.net>
In-Reply-To: <9B6D1255-6580-4DD8-9C83-D1C37B331F95@snigel.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

karl wettin wrote:
> The code is filled with string equality code using == rather than 
> equals(). I honestly don't think it saves a single clock tick as the 
> JIT takes care of it when the first line of code in the equals method 
> is if (this == that) return true;
If the strings are intern() then it should be a touch faster.
If the strings are not interned then I think it may be a premature 
optimization.

IMHO, using intern to optimize space is a reasonable optimization, but 
using == to compare such strings is error prone as it is possible that 
the comparison is looking at strings that have not been interned.

Unless it object identity is what is being tested or intern is an 
invariant, I think it is dangerous. It is easy to forget to intern or to 
propagate the pattern via cut and paste to an inappropriate context.
>
> Please correct me if I'm wrong.
>
> I can commit to do the changes to the core code if it is considered 
> interesting.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org