ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tor Tuga (JIRA)" <ibatis-...@incubator.apache.org>
Subject [jira] Commented: (IBATIS-128) Detect illegal overloaded JavaBeans properties methods (e.g. setters)
Date Wed, 20 Dec 2006 22:50:24 GMT
    [ http://issues.apache.org/jira/browse/IBATIS-128?page=comments#action_12460084 ] 
Tor Tuga commented on IBATIS-128:

I am using Java Generics and this warning gets thrown when I override an abstract method in
a base class with my concrete class.

Reflection shows the following information for getId() and setId() where RealBaseEntity is
the class that extends the abstract class BaseEntity:

            public final void com.test.RealBaseEntity.setId(java.lang.Short)
            public final java.lang.Short com.test.RealBaseEntity.getId()
            public volatile void com.test.RealBaseEntity.setId(java.io.Serializable)
            public volatile java.io.Serializable com.test.RealBaseEntity.getId()

            public abstract void com.test.BaseEntity.setId(java.io.Serializable)
            public abstract java.io.Serializable com.test.BaseEntity.getId()

Now, if I narrow my abstract definition in BaseEntity (elminating the use of Generics), the
following occurs:

            public final void com.test.BaseEntity.setId(java.lang.Short)
            public final java.lang.Short com.test.BaseEntity.getId()

            public abstract void com.test.BaseEntity.setId(java.lang.Short)
            public abstract java.lang.Short com.test.BaseEntity.getId()

The reason that the 'java.lang.Serializable' appears is because my base entity uses generics
in this way:

   public abstract class BaseEntity<PK extends Serializable> implements Serializable

so at compile time, any <PK> is replaced by Serializable. However, RealBaseEntity is
declared in this way:

   public class RealBaseEntity extends BaseEntity<Short>

So I can't really understand why the compiler would bother to create volatile methods if the
final overridden methods are specific enough. I'd be happy to attach the whole BaseEntity
and RealBaseEntity classes if that would help understand what I mean.

I've debugged com.ibatis.common.beans.ClassInfo and I can see that the volatile and final
methods are conflicting causing the error to appear. Couldn't the volatile methods be ignored?
Or, if a method is volatile, couldn't the superclass be checked for an abstract method with
the same signature? This could be done in com.ibatis.common.beans.ClassInfo.addUniqueMethods().
Should I be using an interface instead of an abstract class?

> Detect illegal overloaded JavaBeans properties methods (e.g. setters)
> ---------------------------------------------------------------------
>                 Key: IBATIS-128
>                 URL: http://issues.apache.org/jira/browse/IBATIS-128
>             Project: iBatis for Java
>          Issue Type: Improvement
>          Components: SQL Maps
>    Affects Versions: 2.0.8
>         Environment: iBatis 2.0.7
>            Reporter: Jerome Lacoste
>         Assigned To: Jeff Butler
>            Priority: Minor
>             Fix For: 2.2.0
> ClassInfo keys setters by their names.
> private void addMethods(Class cls) {
>     Method[] methods = cls.getMethods();
>     for (int i = 0; i < methods.length; i++) {
>       String name = methods[i].getName();
>       if (name.startsWith("set") && name.length() > 3) {
>         if (methods[i].getParameterTypes().length == 1) {
>           name = dropCase(name);
> -->        setMethods.put(name, methods[i]);
>           setTypes.put(name, methods[i].getParameterTypes()[0]);
>         }
> See http://cvs.sourceforge.net/viewcvs.py/ibatisdb/ibatis-dbl-2/src/com/ibatis/common/beans/ClassInfo.java?rev=1.8&view=markup
> So if you overload a method in your bean, you never know which one is going to be stored
last in the map.
> With:
>   public void setFeatureIDs(Set featureIDs) {
>     this.featureIDs = featureIDs;
>   }
>   public void setFeatureIDs(List featureIDs) {
>     this.featureIDs = new TreeSet(featureIDs);
>   }
> I end up with the following error:
> Error setting property 'setFeatureIDs(java.util.Set=[2] $Proxy4 implements interface
java.util.List)' of 'Part-20021'. Cause: java.lang.IllegalArgumentException: argument type
mismatch Caused by: java.lang.IllegalArgumentException: argument type mismatch];
> See issue IBATIS-127 for debugging

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message