TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Adam Heath-2
[hidden email] wrote:
> Author: doogie
> Date: Wed Feb 17 17:23:39 2010
> New Revision: 911089
>
> URL: http://svn.apache.org/viewvc?rev=911089&view=rev
> Log:
> Rename millis parameters everywhere to milliseconds.  Also rename the
> millis method.

At this point, I'm mostly done with TimeDuration.  However, there's
one more thing I have to do.  The contract for java.lang.Object says
that if you implement equals, you must implement hashCode against the
same set of fields.  TimeDuration doesn't currently do this.

So, while trying to figure out how to do that exactly, I started
adding some helper methods to UtilObject to make hashCode of multiple
fields easier.  Before that happened tho, I decided to write full test
cases for UtilObject.

So, TimeDuration and UtilObject now have full coverage.
Reply | Threaded
Open this post in threaded view
|

Re: TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Adrian Crum
Adam Heath wrote:

> [hidden email] wrote:
>> Author: doogie
>> Date: Wed Feb 17 17:23:39 2010
>> New Revision: 911089
>>
>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev
>> Log:
>> Rename millis parameters everywhere to milliseconds.  Also rename the
>> millis method.
>
> At this point, I'm mostly done with TimeDuration.  However, there's
> one more thing I have to do.  The contract for java.lang.Object says
> that if you implement equals, you must implement hashCode against the
> same set of fields.  TimeDuration doesn't currently do this.
>
> So, while trying to figure out how to do that exactly, I started
> adding some helper methods to UtilObject to make hashCode of multiple
> fields easier.  Before that happened tho, I decided to write full test
> cases for UtilObject.

Thank you for all your work!

Reply | Threaded
Open this post in threaded view
|

Re: TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Adrian Crum
In reply to this post by Adam Heath-2
Adam Heath wrote:

> [hidden email] wrote:
>> Author: doogie
>> Date: Wed Feb 17 17:23:39 2010
>> New Revision: 911089
>>
>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev
>> Log:
>> Rename millis parameters everywhere to milliseconds.  Also rename the
>> millis method.
>
> At this point, I'm mostly done with TimeDuration.  However, there's
> one more thing I have to do.  The contract for java.lang.Object says
> that if you implement equals, you must implement hashCode against the
> same set of fields.  TimeDuration doesn't currently do this.
>
> So, while trying to figure out how to do that exactly, I started
> adding some helper methods to UtilObject to make hashCode of multiple
> fields easier.  Before that happened tho, I decided to write full test
> cases for UtilObject.
>
> So, TimeDuration and UtilObject now have full coverage.

By the way, now that I fixed the epoch bug, don't you think we can put
advanceCalendar back the way it was? The units argument will always be
positive now.
Reply | Threaded
Open this post in threaded view
|

Re: TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Adam Heath-2
In reply to this post by Adrian Crum
Adrian Crum wrote:

> Adam Heath wrote:
>> [hidden email] wrote:
>>> Author: doogie
>>> Date: Wed Feb 17 17:23:39 2010
>>> New Revision: 911089
>>>
>>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev
>>> Log:
>>> Rename millis parameters everywhere to milliseconds.  Also rename the
>>> millis method.
>>
>> At this point, I'm mostly done with TimeDuration.  However, there's
>> one more thing I have to do.  The contract for java.lang.Object says
>> that if you implement equals, you must implement hashCode against the
>> same set of fields.  TimeDuration doesn't currently do this.
>>
>> So, while trying to figure out how to do that exactly, I started
>> adding some helper methods to UtilObject to make hashCode of multiple
>> fields easier.  Before that happened tho, I decided to write full test
>> cases for UtilObject.
>
> Thank you for all your work!

I don't need thanks.  What I would like, however, is for people to
start doing things similiar to what I do.  I try to provide examples
of how to work the with community software.
Reply | Threaded
Open this post in threaded view
|

Re: TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Adam Heath-2
In reply to this post by Adrian Crum
Adrian Crum wrote:

> Adam Heath wrote:
>> [hidden email] wrote:
>>> Author: doogie
>>> Date: Wed Feb 17 17:23:39 2010
>>> New Revision: 911089
>>>
>>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev
>>> Log:
>>> Rename millis parameters everywhere to milliseconds.  Also rename the
>>> millis method.
>>
>> At this point, I'm mostly done with TimeDuration.  However, there's
>> one more thing I have to do.  The contract for java.lang.Object says
>> that if you implement equals, you must implement hashCode against the
>> same set of fields.  TimeDuration doesn't currently do this.
>>
>> So, while trying to figure out how to do that exactly, I started
>> adding some helper methods to UtilObject to make hashCode of multiple
>> fields easier.  Before that happened tho, I decided to write full test
>> cases for UtilObject.
>>
>> So, TimeDuration and UtilObject now have full coverage.
>
> By the way, now that I fixed the epoch bug, don't you think we can put
> advanceCalendar back the way it was? The units argument will always be
> positive now.

Yeah, I saw what you did.  I was about to commit my flood, but you
just beat me.  There is still full coverage, however, which means my
version of the fix is still being run(all lines, all branches).  I
haven't had time to try and remove it and see if everything still
succeeds.  It might be that there isn't enough testing, and your fix
actually fixes something else.
Reply | Threaded
Open this post in threaded view
|

Re: TimeDuration stuff: Re: svn commit: r911089 - in /ofbiz/trunk/framework/base/src/org/ofbiz/base/util: TimeDuration.java test/TimeDurationTests.java

Adrian Crum
Adam Heath wrote:

> Adrian Crum wrote:
>> Adam Heath wrote:
>>> [hidden email] wrote:
>>>> Author: doogie
>>>> Date: Wed Feb 17 17:23:39 2010
>>>> New Revision: 911089
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev
>>>> Log:
>>>> Rename millis parameters everywhere to milliseconds.  Also rename the
>>>> millis method.
>>> At this point, I'm mostly done with TimeDuration.  However, there's
>>> one more thing I have to do.  The contract for java.lang.Object says
>>> that if you implement equals, you must implement hashCode against the
>>> same set of fields.  TimeDuration doesn't currently do this.
>>>
>>> So, while trying to figure out how to do that exactly, I started
>>> adding some helper methods to UtilObject to make hashCode of multiple
>>> fields easier.  Before that happened tho, I decided to write full test
>>> cases for UtilObject.
>>>
>>> So, TimeDuration and UtilObject now have full coverage.
>> By the way, now that I fixed the epoch bug, don't you think we can put
>> advanceCalendar back the way it was? The units argument will always be
>> positive now.
>
> Yeah, I saw what you did.  I was about to commit my flood, but you
> just beat me.  There is still full coverage, however, which means my
> version of the fix is still being run(all lines, all branches).  I
> haven't had time to try and remove it and see if everything still
> succeeds.  It might be that there isn't enough testing, and your fix
> actually fixes something else.

Never mind. I just re-read your code comments and realized what you're
doing is correct.