http://passanyinterview.com/top-101-core-java-interview-questions/
Kelven
On 2/25/14, 2:07 PM, "Marcus" <shadow...@gmail.com> wrote:
>Also keep in mind that with an Object or custom objects that extend it,
>doing
>
> if (obj.equals(thing))
>
>is usually the same as:
>
> if (obj == thing)
>
>Since the Object.equals() method by default says something like:
>
> public boolean equals(Object other)
> {
> return this == other;
> }
>
>Unless it is overridden, (along with hashCode() from what I
>understand, since Objects deemed 'equal' are supposed to return the
>same hash). So the issue may partially be due to the fact that those
>are largely equivalent in many objects, but not in objects like
>Integer which presumably do something different in their equals()
>implementation. When something works as expected in other
>circumstances it's understandable that the mistake would be made.
>
>I actually fixed a bug recently with resource tags that dealt with
>this, a listVirtualMachines call would duplicate the resource tags,
>sometimes printing up to 8 of the same tag, because someone had done
>"if(!tag1.equals(tag2))", or something expecting to filter duplicates.
>To fix I just implemented the equals() and hashCode() for the resource
>tag object.
>
>
>On Tue, Feb 25, 2014 at 12:19 PM, Suresh Sadhu <suresh.sa...@citrix.com>
>wrote:
>> Thanks Hugo for sharing this valuable info.
>>
>> And also it provides "Different" output when value crosses the Int
>>range
>>
>> public class App
>> {
>> public static void main(String[] args)
>> {
>> Integer a = 128;
>> Integer b = 128;
>>
>> if (a == b) {
>> System.out.println("Equal!");
>> } else {
>> System.out.println("Different!");
>> }
>> }
>> }
>>
>> Output:Different.
>>
>> Regards
>> Sadhu
>>
>>
>>
>>
>> -----Original Message-----
>> From: Min Chen [mailto:min.c...@citrix.com]
>> Sent: 25 February 2014 23:08
>> To: dev@cloudstack.apache.org
>> Subject: Re: Anti-patterns
>>
>> Thanks Hugo for the nice tutorial. In the last example, are you trying
>>to saying this (luckily this time == works although not recommended)
>>
>> public class App
>> {
>> public static void main(String[] args)
>> {
>> Integer a = 1;
>> Integer b = 1;
>>
>> if (a == b) {
>> System.out.println("Equal!");
>> } else {
>> System.out.println("Different!");
>> }
>> }
>> }
>>
>> -min
>>
>>
>>
>>
>> On 2/25/14 5:41 AM, "Hugo Trippaers" <h...@trippaers.nl> wrote:
>>
>>>Anti-pattern:
>>>An anti-pattern (or antipattern) is a common response to a recurring
>>>problem that is usually ineffective and risks being highly
>>>counterproductive. The term, coined in 1995 by Andrew Koenig, was
>>>inspired by a book, Design Patterns, in which the authors highlighted a
>>>number of design patterns in software development that they considered
>>>to be highly reliable and effective.
>>>< source http://en.wikipedia.org/wiki/Anti-pattern
>>>
>>>
>>>Here at Schuberg we spend quite some time going through bugs reports
>>>from automated scanners, you have probably seen the mails coming by on
>>>the ML.
>>>As part of our work we have encountered a number of problems that keep
>>>on popping up in the code base. So here is my first attempt to clarify
>>>why a certain pattern is wrong and hopefully help developers to avoid
>>>this.
>>>
>>>So first up is the equality operator, ==. This operator is commonly
>>>used in many languages to compare if two items are equal. The trick
>>>with this operator in java is to know exactly what you are comparing,
>>>because it matters.
>>>
>>>Consider this piece of code:
>>>
>>>public class App
>>>{
>>> public static void main(String[] args)
>>> {
>>> int a = 1;
>>> int b = 1;
>>>
>>> if (a == b) {
>>> System.out.println("Equal!");
>>> } else {
>>> System.out.println("Different!");
>>> }
>>> }
>>>}
>>>
>>>The expected outcome is ³Equal!² and indeed it prints just that. Now
>>>consider the following code:
>>>
>>>public class App
>>>{
>>> public static void main(String[] args)
>>> {
>>> Integer a = new Integer(1);
>>> Integer b = new Integer(1);
>>>
>>> if (a == b) {
>>> System.out.println("Equal!");
>>> } else {
>>> System.out.println("Different!");
>>> }
>>> }
>>>}
>>>
>>>The result of running this bit of code is ³Different!². With == you are
>>>telling the java compiler to compare the two variables. The variable
>>>are references to Objects, so it will do exactly what you tell it to
>>>do, compare the two object references. As you give it two different
>>>objects, the result willl be ³Different!². The correct way of comparing
>>>the contents of two objects is to use the equals method. Consider the
>>>following piece of code:
>>>
>>>public class App
>>>{
>>> public static void main(String[] args)
>>> {
>>> Integer a = new Integer(1);
>>> Integer b = new Integer(1);
>>>
>>> if (a.equals(b)) {
>>> System.out.println("Equal!");
>>> } else {
>>> System.out.println("Different!");
>>> }
>>> }
>>>}
>>>
>>>
>>>This will again be ³Equals!².
>>>
>>>Why is this often a problem? There are a lot or reasons why these bugs
>>>came to exist in CloudStack (or any other project). For example
>>>somebody might cause this bug by changing the return type of a function
>>>from long to Long. The first one is a primitive which can be compared
>>>with == and the second one is an Object which might result in another
>>>comparison than you intended. Findbugs will catch these types of
>>>comparisons and warn you for them. See commit
>>>d1efdca50622a0b67ae1a286aad3297b1c748e9e for an example.
>>>
>>>
>>>
>>>Oh and what does this print?
>>>
>>>public class App
>>>{
>>> public static void main(String[] args)
>>> {
>>> Integer a = 1;
>>> Integer b = 1;
>>>
>>> if (a.equals(b)) {
>>> System.out.println("Equal!");
>>> } else {
>>> System.out.println("Different!");
>>> }
>>> }
>>>}
>>>
>>>
>>>Surprise!, it prints ³Equals!². This is a boxed integer and java keeps
>>>a pool of these so internally the object is cached and both a and b get
>>>the same objects assigned to them by the internal boxing logic. Just
>>>never rely on this! It only works in specific cases and is
>>>implementation specific per JVM vendor and JVM version.
>>>
>>>Cheers,
>>>
>>>Hugo
>>>
>>>
>>>P.S. If you have another anti pattern feel free to post em in this
>>>thread.
>>>
>>
