Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of min.chen@citrix.com designates
 66.165.176.89 as permitted sender)
From: Min Chen <min.chen@citrix.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: Re: Anti-patterns
Thread-Topic: Anti-patterns
Thread-Index: AQHPMi9oHceYyOgTJkuRqRH6iqgBm5rGPFQA
Date: Tue, 25 Feb 2014 17:38:11 +0000
Message-ID: <CF32141C.551FD%min.chen@citrix.com>
In-Reply-To: <9278EEE9-3FD9-438E-8C3E-D2F1FEA70B65@GMAIL.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.6.130613
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <E2ACE6DA9D738B4AB954F6917033C35C@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks Hugo for the nice tutorial. In the last example, are you trying to
saying this (luckily this time =3D=3D works although not recommended)

public class App
{
	public static void main(String[] args)
	{
		Integer a =3D 1;
		Integer b =3D 1;

		if (a =3D=3D b) {
			System.out.println("Equal!");
		} else {
			System.out.println("Different!");
		}
	}
}

-min


On 2/25/14 5:41 AM, "Hugo Trippaers" <hugo@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.
>=8B 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, =3D=3D.  This operator is commonly u=
sed
>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 =3D 1;
>        int b =3D 1;
>
>        if (a =3D=3D b) {
>            System.out.println("Equal!");
>        } else {
>            System.out.println("Different!");
>        }
>    }
>}
>
>The expected outcome is =B3Equal!=B2 and indeed it prints just that. Now
>consider the following code:
>
>public class App
>{
>    public static void main(String[] args)
>    {
>        Integer a =3D new Integer(1);
>        Integer b =3D new Integer(1);
>
>        if (a =3D=3D b) {
>            System.out.println("Equal!");
>        } else {
>            System.out.println("Different!");
>        }
>    }
>}
>
>The result of running this bit of code is =B3Different!=B2. With =3D=3D yo=
u 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 =B3Different!=B2. 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 =3D new Integer(1);
>        Integer b =3D new Integer(1);
>
>        if (a.equals(b)) {
>            System.out.println("Equal!");
>        } else {
>            System.out.println("Different!");
>        }
>    }
>}
>
>
>This will again be =B3Equals!=B2.
>
>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 =3D=3D an=
d
>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 =3D 1;
>        Integer b =3D 1;
>
>        if (a.equals(b)) {
>            System.out.println("Equal!");
>        } else {
>            System.out.println("Different!");
>        }
>    }
>}
>
>
>Surprise!, it prints =B3Equals!=B2.  This is a boxed integer and java keep=
s 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.
>