I'm guessing for a Cache that has multiple regions that the key/value pairs will likely be different types. But I concede there may be cases where the data types are homogeneous across the cache.

The only downside I see, from a user perspective, is that one might wonder if it is good practice to use a untyped cache.

The best argument against typing, is that as the eventual practice will be to share a different types of data in a single cache, rather than have multiple caches.

Haven't really thought about this, but I'd figure a cache built up by the microcontainer (or any DI framework) would be untyped (i.e. not Cache<Object, Object> but just plain old Cache). You can't cast it to Cache<Object, Object>, so thereafter any calls against the DI-injected cache will give you those lovely compiler warnings.

Not the end of the world, but wanted to point it out as a consideration.

OK, that's not so bad; cuts it down to a single warning, which could be eliminated with a @SuppressWarnings inside getCache(). Accessing a field via a getter isn't a bad practice anyway.

"manik.surtani@jboss.com" wrote:
Well, one workaround is to use a return type rather than a cast, which is valid:
.

public class GenericsFun
{
 private Map<String, Integer> foo = new HashMap<String, Integer>();

 public static void main(String[] args) throws Exception
 {
 HashMap<Long, Long> map = new HashMap<Long, Long>();
 map.put(5L, 6L);
 GenericsFun fun = new GenericsFun();
 Field field = GenericsFun.class.getDeclaredField("foo");
 field.setAccessible(true);
 field.set(fun, map);
 fun.throwCCE();
 }

 public void throwCCE()
 {
 Integer boom = foo.get(5L);
 }
}

DOH!

I spent 1/2 a year working on a really complex Spring app with a lot of genericized stuff. As I was clicking on the 'Submit' button on the 1st post the thought 'hmmm, don't remember having problems with this sort of thing at ...' flashed through my head. But I clicked the button anyway :(

Sorry for the noise; thanks Jason.

"manik.surtani@jboss.com" wrote:
Well, one workaround is to use a return type rather than a cast, which is valid:
.

"jason.greene@jboss.com" wrote:

You don't need to do this. Since a DI framework does this at runtime the generics info is irrelevant. So you can declare the injected type to be whatever you want.

"supi" wrote:

Ok, there will be all kinds of workarounds (subclasses, wrappers, getters etc.) at compile time or (type-less) wiring at runtime that make me think: what's the point? The only benefit I see is type-safety that affects about 2-3 users who only put one kind of objects into the cache. Everyone else has to deal with this new inflexibility in their own way, potentially introducing new bugs, clumsy workarounds, unreadable code, unsafe code (e.g. disable unchecked warnings in whole methods), etc. And lets not forget the cache library itself. More letters, less readable code => more bugs.

In my opinion, at this point a step in the wrong direction.

"jason.greene@jboss.com" wrote:


No worry, workarounds are not needed, you don't have to use generics (just like you don't have to use them with java collections). It's purely syntactic sugar for those that want the additional compiler checking.

-Jason