problem with generics

[GoogleCodeExporter]

I found a problem with generics and in particular with a DAO structure like 
this:
* public interface GenericDAO<T>
* public interface SpecificDAO extends GenericDAO<AppUser>
* public class SpecificDAOImpl implements SpecificDAO

I wrote a test (GenericsTest) that fails with the current code of 
simple-spring-memcached.
The only solution that I found is to add a new annotation (@GenericsBridged).

I attach the classes that I modified (from simple-spring-memcached 
2.0.0-SNAPSHOT).

Chiara Zambelli

Original issue reported on code.google.com by chiara.z...@know.eu on 9 Jan 2012 at 10:28

Attachments:

• simple-spring-memcached-patch-generics.tgz

[GoogleCodeExporter]

Thanks for the bug report and patch.
I'm going to apply this patch to trunk before releasing next version (2.0.0).

Original comment by ragno...@gmail.com on 9 Jan 2012 at 11:15

• Changed state: Accepted

[GoogleCodeExporter]

Unfortunately attached patch will work only with bridge methods having the same 
amount and order of parameters as defined in @GenericsBridged annotation and 
with proper type of parameters.
Example:
{code}
public interface Generic<K,V> {

 //  amount and order of parameters and is the same as in @GenericsBridged and types of parameters are appropriate
  void set(K key, V value);

// wrong, method has different amount of parameters than @GenericsBridged
  V get(K key);

  // wrong, method has different amount of parameters than @GenericsBridged
  void put(K key, V value, boolean overwrite);

}

public interface Specific extends Generic<String, Integer> {}

//@GenericsBridged(classes={String.class, Integer.class})
public class SpecificImpl implements Specific {

  @BridgeMethodParams({String.class, Integer.class})
  public void set(String key, Integer value) {
  ....
  }

  @BridgeMethodParams({String.class})
  public Integer get(String key) {
  .....
  }

  @BridgeMethodParams({String.class, Integer.class, boolean.class}) 
  public void put(String key, Integer value, boolean overwrite) {
  ....
  }

}
{code}

One of the fix that I see is to use annotation on method. Dedicated annotation 
@BridgeMethodParams contains types of annotated method's parameters in 
appropriate order. The downside is that in same cases developer will have to 
put many @BridgeMethodParams in his class.

Original comment by ragno...@gmail.com on 11 Jan 2012 at 6:54

[GoogleCodeExporter]

I agree with your idea to use annotation on method (even considering the 
downside). In this manner the code can work also in the situation that you 
explained.

Original comment by chiara.z...@know.eu on 11 Jan 2012 at 8:54

[GoogleCodeExporter]

This approach with @BridgeMethodParams doesn't work. If it worked it wouldn't 
be necessary because fetching directly @*Cache annotation would work also. The 
only solution that I see is to use type annotation with some mappings for each 
bridged method.

@BridgeMethodMappings({
@BridgeMethodMapping(name = "set", erasedParamTypes = {Object.class, 
Object.class}, targetParamTypes = {String.class, Integer.class}),
@BridgeMethodMapping(name = "get", erasedParamTypes = {Object.class}, 
targetParamTypes = {String.class}),
@BridgeMethodMapping(name = "put", erasedParamTypes = {Object.class, 
Object.class, boolean.class}, targetParamTypes = {String.class, Integer.class, 
boolean.class})
)}
public class SpecificImpl implements Specific {
.....
}

This requires many additional annotations and knowledge about java type erasure.

Original comment by ragno...@gmail.com on 11 Jan 2012 at 7:31

[GoogleCodeExporter]

Code in trunk.

Original comment by ragno...@gmail.com on 31 Jan 2012 at 8:53

• Changed state: Fixed