search

lishunli / projectlombok

Automatically exported from code.google.com/p/projectlombok
0 stars 0 forks source link

Equals Method enhancement #580

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It would be nice to have log messages (which can be printed during debug mode 
etc) around equals method failure i.e when equals fails, it is better to 
directly know which condition has failed.. this can substantially reduce debug 
time when many classes and many fields exist in Domain Model.

Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com

Original issue reported on code.google.com by nagendra...@gmail.com on 23 Sep 2013 at 6:06

GoogleCodeExporter commented 9 years ago 
Just to get this clear: you will get debug messages for EACH call of ANY 
equals() method created by lombok that would return 'false' - so not only if 
they aren't equal when they should be, but also when they should actually not 
be. How do you know which one is the case? Lombok doesn't have any knowledge 
about your code and what it represents, so you will have to check each and 
every message yourself. I can't imagine you would want that. 

Besides, I really hope that there is a certain point in your code at which you 
know that two objects should be equal (otherwise, where do you start? Go 
through random calls of equals() and check if they succeed or not?). So can't 
you just System.out.println objects 1 and 2? Use @ToString for a human readable 
representation and you'll see where the objects differ.

I say this isn't boilerplate and I'll close the issue. If you have a really 
good use case and clear example, by all means, please discuss further on the 
mailinglist: https://groups.google.com/forum/#!forum/project-lombok

Original comment by askon...@gmail.com on 7 Oct 2013 at 6:27

GoogleCodeExporter commented 9 years ago 
The debug intent is to say which field in which class of the highterarchity 
failed on  match directly..

e.g.. my test case assert fails.. like this..to identify which match failed is 
a real time consuming.. and can be easily pointed by debug version.. saying two 
calenders did not match etc..

     [java] 3) testUnMarshalEnum(com.tejasoft.tezzd.model.rdo.profile.basic.fetc
h.test.TestFetchUserResponse)junit.framework.AssertionFailedError: expected:<Fet
chUserInfoResponse(userInfoFDO=UserInfoFDO(user=User(loginID=null, password=abc1
23, phone=null, email=null, name=ramesh nagendra, extInfo=UserExtInfo(gender=FEM
ALE, title=C.T.O, dob=java.util.GregorianCalendar[time=1381381973000,areFieldsSe
t=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asi
a/Calcutta",offset=19800000,dstSavings=0,useDaylight=false,transitions=6,lastRul
e=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2013,MONTH=9,WEEK_O
F_YEAR=41,WEEK_OF_MONTH=2,DAY_OF_MONTH=10,DAY_OF_YEAR=283,DAY_OF_WEEK=5,DAY_OF_W
EEK_IN_MONTH=2,AM_PM=0,HOUR=10,HOUR_OF_DAY=10,MINUTE=42,SECOND=53,MILLISECOND=0,
ZONE_OFFSET=19800000,DST_OFFSET=0], passwordAO=null, passwordVO=null))))> but wa
s:<FetchUserInfoResponse(userInfoFDO=UserInfoFDO(user=User(loginID=null, passwor
d=abc123, phone=null, email=null, name=ramesh nagendra, extInfo=UserExtInfo(gend
er=FEMALE, title=C.T.O, dob=java.util.GregorianCalendar[time=1381381973962,areFi
eldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[i
d="Asia/Calcutta",offset=19800000,dstSavings=0,useDaylight=false,transitions=6,l
astRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2013,MONTH=9,
WEEK_OF_YEAR=41,WEEK_OF_MONTH=2,DAY_OF_MONTH=10,DAY_OF_YEAR=283,DAY_OF_WEEK=5,DA
Y_OF_WEEK_IN_MONTH=2,AM_PM=0,HOUR=10,HOUR_OF_DAY=10,MINUTE=42,SECOND=53,MILLISEC
OND=962,ZONE_OFFSET=19800000,DST_OFFSET=0], passwordAO=null, passwordVO=null))))
>

Original comment by nagendra...@gmail.com on 10 Oct 2013 at 5:20

GoogleCodeExporter commented 9 years ago 
This makes sense, but there's no sane way for equals to do this. Logging what 
fields differ would mean a big slowdown and an even bigger mess in the 
logfiles. You'd have to switch it on just before the failure. As the result is 
boolean, no additional information can be returned.

I could imagine that generating a separate method like `void 
assertEquals(Object other)` with a detailed message in the exception makes 
sense, but I'm afraid the lombok authors don't see it as useful enough.

As a simple workaround try

if (!a.equals(b)) {
    assertEquals(a.toString(), b.toString());
    fail("WTF?");
}

Now JUnit should show you exactly where the strings differ and this could be 
enough.

Original comment by Maaarti...@gmail.com on 20 Oct 2013 at 5:44

GoogleCodeExporter commented 9 years ago 
This is a great work around suggestion to use  JUnit Asserter.
Thank You Maarti. I can make this required changes in delombok code and make it 
work locally to my need.

Original comment by nagendra...@gmail.com on 10 Nov 2013 at 12:28