You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Vincenzo Vitale (JIRA)" <ji...@apache.org> on 2008/07/08 01:32:31 UTC
[jira] Created: (BEANUTILS-320) Implement equals, hashCode and
toString replacement
Implement equals, hashCode and toString replacement
---------------------------------------------------
Key: BEANUTILS-320
URL: https://issues.apache.org/jira/browse/BEANUTILS-320
Project: Commons BeanUtils
Issue Type: New Feature
Components: Bean / Property Utils
Reporter: Vincenzo Vitale
Priority: Minor
In my company (TomTom), I have internally developed a replacement of the equals, hashcode and toString methods.
The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
@Override
public boolean equals(Object obj) {
return BeanUtils.equals(this, obj);
}
@Override
public int hashCode() {
return BeanUtils.hashCode(this);
}
@Override
public String toString() {
return BeanUtils.toString(this);
}
And i.e. the method signature of equals is:
/**
* Compare two @BusinessObject beans comparing only the {@link BusinessField}
* annotated fields.
*
* @param firstBean First bean to compare.
* @param secondBean Second bean to compare.
* @return The equals result.
* @throws IllegalArgumentException If one of the beans compared is not an
* instance of a {@link BusinessObject} annotated class.
*/
public static boolean equals(Object firstBean, Object secondBean);
In the last versions of EqaulsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
For example if all my business logic cares only about the color, I can define:
@BusinessObject
public class Cat{
}
public class ColouredCat extends Cat{
@BusinessField
private String color;
getter/setter
}
@BusinessObject
public class SunSet{
@BusinessField
private String color="red";
getter/setter
}
and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
We always thought about the possibility to create a new Open Source project but the it was decided than probably it would be better to add the feature to an already well know open source project.
If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
Thanks in advance,
Vicio.
P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (BEANUTILS-320) Implement equals, hashCode and
toString replacement
Posted by "Vincenzo Vitale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BEANUTILS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vincenzo Vitale updated BEANUTILS-320:
--------------------------------------
Description:
In my company (TomTom), we have internally developed a replacement of the equals, hashcode and toString methods.
The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
@Override
public boolean equals(Object obj) {
return BeanUtils.equals(this, obj);
}
@Override
public int hashCode() {
return BeanUtils.hashCode(this);
}
@Override
public String toString() {
return BeanUtils.toString(this);
}
And i.e. the method signature of equals is:
/**
* Compare two @BusinessObject beans comparing only the {@link BusinessField}
* annotated fields.
*
* @param firstBean First bean to compare.
* @param secondBean Second bean to compare.
* @return The equals result.
* @throws IllegalArgumentException If one of the beans compared is not an
* instance of a {@link BusinessObject} annotated class.
*/
public static boolean equals(Object firstBean, Object secondBean);
In the last versions of EqualsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
For example if all my business logic cares only about the color, I can define:
@BusinessObject
public class Cat{
}
public class ColouredCat extends Cat{
@BusinessField
private String color;
getter/setter
}
@BusinessObject
public class SunSet{
@BusinessField
private String color="red";
getter/setter
}
and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
We always thought about the possibility to create a new Open Source project but then it was decided it would be better adding the feature to an already well know open source project...
If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
Thanks in advance,
Vicio.
P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
was:
In my company (TomTom), I have internally developed a replacement of the equals, hashcode and toString methods.
The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
@Override
public boolean equals(Object obj) {
return BeanUtils.equals(this, obj);
}
@Override
public int hashCode() {
return BeanUtils.hashCode(this);
}
@Override
public String toString() {
return BeanUtils.toString(this);
}
And i.e. the method signature of equals is:
/**
* Compare two @BusinessObject beans comparing only the {@link BusinessField}
* annotated fields.
*
* @param firstBean First bean to compare.
* @param secondBean Second bean to compare.
* @return The equals result.
* @throws IllegalArgumentException If one of the beans compared is not an
* instance of a {@link BusinessObject} annotated class.
*/
public static boolean equals(Object firstBean, Object secondBean);
In the last versions of EqaulsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
For example if all my business logic cares only about the color, I can define:
@BusinessObject
public class Cat{
}
public class ColouredCat extends Cat{
@BusinessField
private String color;
getter/setter
}
@BusinessObject
public class SunSet{
@BusinessField
private String color="red";
getter/setter
}
and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
We always thought about the possibility to create a new Open Source project but the it was decided than probably it would be better to add the feature to an already well know open source project.
If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
Thanks in advance,
Vicio.
P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
Just corrected a typo.
> Implement equals, hashCode and toString replacement
> ---------------------------------------------------
>
> Key: BEANUTILS-320
> URL: https://issues.apache.org/jira/browse/BEANUTILS-320
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Reporter: Vincenzo Vitale
> Priority: Minor
>
> In my company (TomTom), we have internally developed a replacement of the equals, hashcode and toString methods.
> The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
> @Override
> public boolean equals(Object obj) {
> return BeanUtils.equals(this, obj);
> }
> @Override
> public int hashCode() {
> return BeanUtils.hashCode(this);
> }
> @Override
> public String toString() {
> return BeanUtils.toString(this);
> }
> And i.e. the method signature of equals is:
> /**
> * Compare two @BusinessObject beans comparing only the {@link BusinessField}
> * annotated fields.
> *
> * @param firstBean First bean to compare.
> * @param secondBean Second bean to compare.
> * @return The equals result.
> * @throws IllegalArgumentException If one of the beans compared is not an
> * instance of a {@link BusinessObject} annotated class.
> */
> public static boolean equals(Object firstBean, Object secondBean);
> In the last versions of EqualsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
> The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
> For example if all my business logic cares only about the color, I can define:
> @BusinessObject
> public class Cat{
> }
> public class ColouredCat extends Cat{
> @BusinessField
> private String color;
> getter/setter
> }
> @BusinessObject
> public class SunSet{
> @BusinessField
> private String color="red";
> getter/setter
> }
> and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
> We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
> We always thought about the possibility to create a new Open Source project but then it was decided it would be better adding the feature to an already well know open source project...
> If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
> Thanks in advance,
> Vicio.
> P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-320) Implement equals, hashCode and
toString replacement
Posted by "Vincenzo Vitale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BEANUTILS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611973#action_12611973 ]
Vincenzo Vitale commented on BEANUTILS-320:
-------------------------------------------
Hi Niall,
thanks for the comment.
I think you are right, commons lang will be more appropriate... I will new improvement file there.
BTW, I also created yesterday a project in GoogleCode for this http://code.google.com/p/simplestuff/ , just to beginning the "coming out" :-)
Thanks,
V.
> Implement equals, hashCode and toString replacement
> ---------------------------------------------------
>
> Key: BEANUTILS-320
> URL: https://issues.apache.org/jira/browse/BEANUTILS-320
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Reporter: Vincenzo Vitale
> Priority: Minor
>
> In my company (TomTom), we have internally developed a replacement of the equals, hashcode and toString methods.
> The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
> @Override
> public boolean equals(Object obj) {
> return BeanUtils.equals(this, obj);
> }
> @Override
> public int hashCode() {
> return BeanUtils.hashCode(this);
> }
> @Override
> public String toString() {
> return BeanUtils.toString(this);
> }
> And i.e. the method signature of equals is:
> /**
> * Compare two @BusinessObject beans comparing only the {@link BusinessField}
> * annotated fields.
> *
> * @param firstBean First bean to compare.
> * @param secondBean Second bean to compare.
> * @return The equals result.
> * @throws IllegalArgumentException If one of the beans compared is not an
> * instance of a {@link BusinessObject} annotated class.
> */
> public static boolean equals(Object firstBean, Object secondBean);
> In the last versions of EqualsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
> The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
> For example if all my business logic cares only about the color, I can define:
> @BusinessObject
> public class Cat{
> }
> public class ColouredCat extends Cat{
> @BusinessField
> private String color;
> getter/setter
> }
> @BusinessObject
> public class SunSet{
> @BusinessField
> private String color="red";
> getter/setter
> }
> and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
> We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
> We always thought about the possibility to create a new Open Source project but then it was decided it would be better adding the feature to an already well know open source project...
> If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
> Thanks in advance,
> Vicio.
> P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (BEANUTILS-320) Implement equals, hashCode and
toString replacement
Posted by "Vincenzo Vitale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BEANUTILS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vincenzo Vitale closed BEANUTILS-320.
-------------------------------------
Resolution: Duplicate
The new improvement reuqest created for the Lang project :
https://issues.apache.org/jira/browse/LANG-449
> Implement equals, hashCode and toString replacement
> ---------------------------------------------------
>
> Key: BEANUTILS-320
> URL: https://issues.apache.org/jira/browse/BEANUTILS-320
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Reporter: Vincenzo Vitale
> Priority: Minor
>
> In my company (TomTom), we have internally developed a replacement of the equals, hashcode and toString methods.
> The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
> @Override
> public boolean equals(Object obj) {
> return BeanUtils.equals(this, obj);
> }
> @Override
> public int hashCode() {
> return BeanUtils.hashCode(this);
> }
> @Override
> public String toString() {
> return BeanUtils.toString(this);
> }
> And i.e. the method signature of equals is:
> /**
> * Compare two @BusinessObject beans comparing only the {@link BusinessField}
> * annotated fields.
> *
> * @param firstBean First bean to compare.
> * @param secondBean Second bean to compare.
> * @return The equals result.
> * @throws IllegalArgumentException If one of the beans compared is not an
> * instance of a {@link BusinessObject} annotated class.
> */
> public static boolean equals(Object firstBean, Object secondBean);
> In the last versions of EqualsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
> The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
> For example if all my business logic cares only about the color, I can define:
> @BusinessObject
> public class Cat{
> }
> public class ColouredCat extends Cat{
> @BusinessField
> private String color;
> getter/setter
> }
> @BusinessObject
> public class SunSet{
> @BusinessField
> private String color="red";
> getter/setter
> }
> and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
> We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
> We always thought about the possibility to create a new Open Source project but then it was decided it would be better adding the feature to an already well know open source project...
> If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
> Thanks in advance,
> Vicio.
> P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-320) Implement equals, hashCode and
toString replacement
Posted by "Vincenzo Vitale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BEANUTILS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611984#action_12611984 ]
Vincenzo Vitale commented on BEANUTILS-320:
-------------------------------------------
Created a new improvement request for Lang project:
https://issues.apache.org/jira/browse/LANG-449
> Implement equals, hashCode and toString replacement
> ---------------------------------------------------
>
> Key: BEANUTILS-320
> URL: https://issues.apache.org/jira/browse/BEANUTILS-320
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Reporter: Vincenzo Vitale
> Priority: Minor
>
> In my company (TomTom), we have internally developed a replacement of the equals, hashcode and toString methods.
> The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
> @Override
> public boolean equals(Object obj) {
> return BeanUtils.equals(this, obj);
> }
> @Override
> public int hashCode() {
> return BeanUtils.hashCode(this);
> }
> @Override
> public String toString() {
> return BeanUtils.toString(this);
> }
> And i.e. the method signature of equals is:
> /**
> * Compare two @BusinessObject beans comparing only the {@link BusinessField}
> * annotated fields.
> *
> * @param firstBean First bean to compare.
> * @param secondBean Second bean to compare.
> * @return The equals result.
> * @throws IllegalArgumentException If one of the beans compared is not an
> * instance of a {@link BusinessObject} annotated class.
> */
> public static boolean equals(Object firstBean, Object secondBean);
> In the last versions of EqualsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
> The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
> For example if all my business logic cares only about the color, I can define:
> @BusinessObject
> public class Cat{
> }
> public class ColouredCat extends Cat{
> @BusinessField
> private String color;
> getter/setter
> }
> @BusinessObject
> public class SunSet{
> @BusinessField
> private String color="red";
> getter/setter
> }
> and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
> We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
> We always thought about the possibility to create a new Open Source project but then it was decided it would be better adding the feature to an already well know open source project...
> If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
> Thanks in advance,
> Vicio.
> P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-320) Implement equals, hashCode and
toString replacement
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BEANUTILS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611957#action_12611957 ]
Niall Pemberton commented on BEANUTILS-320:
-------------------------------------------
BeanUtils is currently a minimum of JDK 1.3 and the next release (1.8.0) will stay with that to be compatibile. I did a 1.8.0 beta release last year(!) but haven't yet got round to finishing up for the final 1.8.0 release. So this type of change would have to go in BeanUtils 2.0, with a move to JDK 1.5 as a minimum. Realistically though I doubt this will ever happen since BeanUtils is at best in maintenance mode.
Also my first thought was that this would be more appropriate in Commons Lang - which already provides equals/hashcode/toString functionality in its *builder* package (whereas BeanUtils doesn't currently):
http://commons.apache.org/lang/api-release/org/apache/commons/lang/builder/package-summary.html
> Implement equals, hashCode and toString replacement
> ---------------------------------------------------
>
> Key: BEANUTILS-320
> URL: https://issues.apache.org/jira/browse/BEANUTILS-320
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Reporter: Vincenzo Vitale
> Priority: Minor
>
> In my company (TomTom), we have internally developed a replacement of the equals, hashcode and toString methods.
> The base idea is to use the annotation @BusinessObject at the class level and @BusinessField at field level. Then what developers normally do is to override the three methods delegating to the tomtom.BeanUtils methods:
> @Override
> public boolean equals(Object obj) {
> return BeanUtils.equals(this, obj);
> }
> @Override
> public int hashCode() {
> return BeanUtils.hashCode(this);
> }
> @Override
> public String toString() {
> return BeanUtils.toString(this);
> }
> And i.e. the method signature of equals is:
> /**
> * Compare two @BusinessObject beans comparing only the {@link BusinessField}
> * annotated fields.
> *
> * @param firstBean First bean to compare.
> * @param secondBean Second bean to compare.
> * @return The equals result.
> * @throws IllegalArgumentException If one of the beans compared is not an
> * instance of a {@link BusinessObject} annotated class.
> */
> public static boolean equals(Object firstBean, Object secondBean);
> In the last versions of EqualsBuilder now there is the new method reflectionEquals... but there is no a way to specify what to include in the comparison. With our two annotations we are able to let developers exactly define what need to be included in a Business comparison, as i.e. normally required by persistence framework like hibernate.
> The current implementation can also handle more complex case, comparing correctly totally different kind of objects.
> For example if all my business logic cares only about the color, I can define:
> @BusinessObject
> public class Cat{
> }
> public class ColouredCat extends Cat{
> @BusinessField
> private String color;
> getter/setter
> }
> @BusinessObject
> public class SunSet{
> @BusinessField
> private String color="red";
> getter/setter
> }
> and then compare any instance of ColouredCat with a Sunset instance, finding out that the redColouredCat is (for my business logic) equal to a default instance of a Sunset. And also more tricky cases are handled (different BusinessFields, no BusinessObject annotation and so on).
> We intensively use Hibernate and the utility demonstrated to work fine with CGLIB proxies
> We always thought about the possibility to create a new Open Source project but then it was decided it would be better adding the feature to an already well know open source project...
> If you are interested I can send you more details. How can we (me more one other developer) eventually became committers?
> Thanks in advance,
> Vicio.
> P.s.: an utility method to automatically populate the BusinessFields of a BusinessObject is also implemented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.