tag:blogger.com,1999:blog-67454987979659135162024-09-04T19:48:23.258-07:00Ashutoshhttp://www.blogger.com/profile/13099288373508604808noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-6745498797965913516.post-52971140653022100842012-05-31T09:04:00.000-07:002012-05-31T09:36:54.749-07:00<div dir="ltr" style="text-align: left;" trbidi="on"> Look inside the blog<br /> by Peter :&nbsp;<a href="http://unitstep.net/blog/2009/05/18/resolving-log4j-1215-dependency-problems-in-maven-using-exclusions/">Log4j 1.2.15 Maven Dependency Problem</a>&nbsp; &lt;&lt; exclude unwanted dependencies&gt;<br /> <div style="text-align: -webkit-auto;"> by&nbsp;<span style="background-color: white; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; line-height: 20px; text-align: -webkit-auto;">Simon</span><span style="background-color: white; font-family: Verdana, Arial, Helvetica, sans-serif; text-align: -webkit-auto;"><span style="font-size: 12px; line-height: 20px;">&nbsp;:&nbsp;</span><a href="http://onemanwenttomow.wordpress.com/2007/12/31/maven2-log4j-and-jmx-dependencies/" style="font-size: 12px; line-height: 20px;">Log4j 1.2.15 Maven Dependency Problem</a><span style="font-size: 12px; line-height: 20px;">&nbsp;&lt;&lt; manual&nbsp;registration of required jars into maven repository &gt;&gt;</span></span></div> </div>Ashutoshhttp://www.blogger.com/profile/13099288373508604808noreply@blogger.com0tag:blogger.com,1999:blog-6745498797965913516.post-17052162012005189622010-05-22T04:00:00.001-07:002010-05-22T05:18:34.559-07:00Well it was seeming just another day in Office when a piece of checked in code caught my attention. It led to a constructive debate in the team and eventually we arrived at the conclusion as mentioned below.<br />I had used .equals() to compare two Enums as we all know that Object.equals() internally uses == operator two compare two references and for Enums which is true as two equal enums will always point to the same memory location as they are singleton in nature. I considered .equals() a comfortable and a standard way of comparing two Objects which could also be applied to Enums as well.<br />Here comes the different side of the story.The argument was Enums are basically constants and the convention is we should use == to compare constants. Since it didn't seem to be very convincing to me as object .equals() does the same thing and enum is not a primitive datatype like int etc, I decided to google on it.<br /><br />It came out that using == over .equals() is more advantageous in two ways:<br /><br />a) It gives you a compile time advantage. How? See below .<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://schneide.files.wordpress.com/2008/09/enum_comparison.png"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 397px; height: 211px;" src="http://schneide.files.wordpress.com/2008/09/enum_comparison.png" alt="" border="0" /></a><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />Comparing the <code>EState</code> enum with an <code>ILamp</code> using equals() is accepted perfectly by the compiler even though the condition never can be true in practice. Using <code>==</code> the compiler screams and tells us that we are comparing apples with oranges.<br /><br />b)One can avoid the accidental and unwanted null pointer exceptions using == operator over .equals() making it null safe.<br /><br />Though the second problem can be avoided, the first one seems to be a cool advantage during development<br /><br />The interesting articles that i came across on this topic are below:<br /><a href="http://schneide.wordpress.com/2008/09/22/or-equals/">http://schneide.wordpress.com/2008/09/22/or-equals/</a><br /><a href="http://stackoverflow.com/questions/1750435/comparing-java-enum-members-or-equals">http://stackoverflow.com/questions/1750435/comparing-java-enum-members-or-equals</a>Ashutoshhttp://www.blogger.com/profile/13099288373508604808noreply@blogger.com0