Re: [JBoss-dev] Verify primary key implements equals and hashCode
hi dain, On Thu, 2003-03-27 at 02:37, Dain Sundstrom wrote: Who maintains the verifier? i do. shall i integrate yours/victors proposal? best regards, christian --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verify primary key implements equals and hashCode
Dain Sundstrom wrote:
On Wednesday, March 26, 2003, at 09:29 PM, Victor Langelo wrote:
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity.
These are derived from generic pk classes when the primary key data
is a simple primative type. The super class implements equals,
compareTo and hashCode. I don't see any reason these would need to be
reimplemented in each derived class.
The purpose of the derived classes is primarly for type safety.
I should have added that our client side framework depends on there
being different classes for each domain type. For instance if you double
click on a refund in a list of transactions we need to know to open the
form for editing/viewing a refund instead of one for editing payments.
I loaned my copy of Effective Java to a friend so I can't quote. The
basic idea is that if a.equals(b) is true b.equals(a) must also be
true. This means you must test for the exact type of the related
compare to object. You must have code that looks something like this.
public boolean equals(object o)
{
if(o instanceof MyType)
{
return value.equals((MyType).value);
}
return false;
}
The important part is the instance of check. I suppose you could do
this check with reflection... something like this
if(getClass() == o.getClass())
Agreed. We do something similar. Due to class loader issues, it isn't
always that simple :(
So I guess you are right, but we know that if one of the super classes
(other then Object) we know that the implementation is wrong.
I sorry, but I don't understand this statement at all.
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod(equals, params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
That should work.
-dain
--Victor
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Verify primary key implements equals and hashCode
I think it is reasonable to validate that the default implementation in
java.lang.Object has been overridden, but beyond that the developer
should be left to shoot themselves in the foot. I too have used Victor's
pattern of a common abstract base class that contained the
implementation and that was then subclassed for type safety.
I also believe that any move toward support of inheritance for
implementations would also require support for inheritance of the
associated identity. EJB may not support this, but other frameworks
might.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dain Sundstrom
Sent: Wednesday, March 26, 2003 9:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] Verify primary key implements equals
and hashCode
On Wednesday, March 26, 2003, at 09:29 PM, Victor Langelo wrote:
Dain Sundstrom wrote:
After some email with Bill, it looks like we can use
Class.getDeclaredMethods to find which method the class implements
(you learn something new every day). It specifically excludes
inherited methods, so we can use it to verify if a primary key has
actually implemented hashCode and equals.
Class.getDeclaredMethod(equals, new Class[] {
Object.class }) should
also do the trick and won't return inherited methods.
I dumb; I missed that one.
Since equals equals is not really inheritable (see
Effective Java), I
think we should throw a verifier error if a pk does not directly
implement it.
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity.
These are derived from generic pk classes when the primary
key data is
a simple primative type. The super class implements equals,
compareTo
and hashCode. I don't see any reason these would need to be
reimplemented in each derived class.
The purpose of the derived classes is primarly for type safety.
I loaned my copy of Effective Java to a friend so I can't quote. The
basic idea is that if a.equals(b) is true b.equals(a) must also be
true. This means you must test for the exact type of the related
compare to object. You must have code that looks something like this.
public boolean equals(object o)
{
if(o instanceof MyType)
{
return value.equals((MyType).value);
}
return false;
}
The important part is the instance of check. I suppose you could do
this check with reflection... something like this
if(getClass() == o.getClass())
So I guess you are right, but we know that if one of the
super classes
(other then Object) we know that the implementation is wrong.
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod(equals, params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
That should work.
-dain
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verify primary key implements equals and hashCode
Dain Sundstrom wrote:
After some email with Bill, it looks like we can use
Class.getDeclaredMethods to find which method the class implements
(you learn something new every day). It specifically excludes
inherited methods, so we can use it to verify if a primary key has
actually implemented hashCode and equals.
Class.getDeclaredMethod(equals, new Class[] { Object.class }) should
also do the trick and won't return inherited methods.
Since equals equals is not really inheritable (see Effective Java), I
think we should throw a verifier error if a pk does not directly
implement it.
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity. These
are derived from generic pk classes when the primary key data is a
simple primative type. The super class implements equals, compareTo and
hashCode. I don't see any reason these would need to be reimplemented in
each derived class.
The purpose of the derived classes is primarly for type safety.
HashCode on the other hand can be inherited (and still be valid), so I
think we should only print a warning if they don't directly. We could
check the parents until we get to Object to see if they left the
default implementation.
Who maintains the verifier?
-dain
Here is the code I wrote in to test this:
public static boolean definesEquals(Class clazz)
{
Method[] method = clazz.getDeclaredMethods();
for(int i=0; imethod.length; i++)
{
if(method[i].getName().equals(equals)
method[i].getParameterTypes().length == 1
method[i].getParameterTypes()[0] == Object.class
method[i].getReturnType() == Boolean.TYPE)
{
return true;
}
}
return false;
}
How about: (off the cuff and untested)
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod(equals, params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
--Victor Langelo
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verify primary key implements equals and hashCode
On Wednesday, March 26, 2003, at 09:29 PM, Victor Langelo wrote:
Dain Sundstrom wrote:
After some email with Bill, it looks like we can use
Class.getDeclaredMethods to find which method the class implements
(you learn something new every day). It specifically excludes
inherited methods, so we can use it to verify if a primary key has
actually implemented hashCode and equals.
Class.getDeclaredMethod(equals, new Class[] { Object.class }) should
also do the trick and won't return inherited methods.
I dumb; I missed that one.
Since equals equals is not really inheritable (see Effective Java), I
think we should throw a verifier error if a pk does not directly
implement it.
I haven't read Effective Java, but this won't work for us. We
intentionally create derived primary key classes for each entity.
These are derived from generic pk classes when the primary key data is
a simple primative type. The super class implements equals, compareTo
and hashCode. I don't see any reason these would need to be
reimplemented in each derived class.
The purpose of the derived classes is primarly for type safety.
I loaned my copy of Effective Java to a friend so I can't quote. The
basic idea is that if a.equals(b) is true b.equals(a) must also be
true. This means you must test for the exact type of the related
compare to object. You must have code that looks something like this.
public boolean equals(object o)
{
if(o instanceof MyType)
{
return value.equals((MyType).value);
}
return false;
}
The important part is the instance of check. I suppose you could do
this check with reflection... something like this
if(getClass() == o.getClass())
So I guess you are right, but we know that if one of the super classes
(other then Object) we know that the implementation is wrong.
public static boolean definesEquals(Class clazz)
{
Class[] params = new Class[] { Object.class };
while (clazz != null !clazz.equals(Object.class)) {
try {
Method m = clazz.getDeclaredMethod(equals, params);
if (m.getReturnType() == Integer.TYPE)
return true;
} catch (NoSuchMethodException) {
}
clazz = clazz.getSuperclass();
}
return false;
}
That should work.
-dain
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
