tags:

views:

39

answers:

1

I'm using a HashMap and the method show below to track change listeners for class types. The IDE is giving a warning

[rawtypes] found raw type: java.lang.Class
  missing type parameters for generic class java.lang.Class<T>. 

What type for Class needs to be specified to resolve the warning?

private HashMap<Class, Set<ChangeListener>> classChangeListeners;

/**
 * Adds a ChangeListener to the listener list for the specified class type. The class type
 * specified must be a subclass of {@link BusinessObject}.
 *
 * @param  <T>  the type of BusinessObject.
 * @param  cls  the class type.
 * @param  listener  the ChangeListener to be added.
 */
public <T extends BusinessObject> void addChangeListener(Class<T> cls, ChangeListener listener)
{
 if (!classChangeListeners.containsKey(cls))
 {
  classChangeListeners.put(cls, new TreeSet<ChangeListener>());
 }

 classChangeListeners.get(cls).add(listener);
}
+3  A: 

If you don't care to specify the type of the particular Classes you are working with, you can use Class<?> instead of the raw type Class.

In some cases you'd want to wildcard it, Class<? extends BusinessObject> or parametrize it, Class<T> - but usually Class<?> will be sufficient, and it's hard to infer what you actually want from a short snippet.

Also, it looks like you're using a Map containing Sets. You could look into using a Multimap which has this functionality built in and makes it a lot nicer to work with.

Steven Schlansker
From the looks of your code, apparently Class<? extends BusinessObject> would be most appropriate.
Carl Manaster
As long as the invariant documented on the method actually holds for the Map itself (where it's not documented explicitly), I'd agree...
Steven Schlansker
I suppose it depends on what a ChangeListener can handle. If it can only handle BusinessObjects, then I would go with Carl's suggestion. If it doesn't matter, I would write Class<?>. (In general, I prefer <Object> rather than <?> in a data structure because it makes it clear that we're working within a type hierarchy, but Class<Object> means something specific that we don't want.)
Justin K