The way Listeners work they are only half typed, which is unfortunate. It determines what method to invoke solely on annotations, so Listener methods can define any type for the Event that they want. The developer using a Converter would have to be cognizant that they should be the same or super type for the listener they use. Specifically CacheEntryEvent<K, V> the type V must match or be a super type of C defined on the Converter<K, V, C> if a converter is provided, but there are no compile checks for this :( Eg. @Listener class SomeListener { @CacheEntryCreated public void handleEvent(CacheEntryEvent<String, Integer> event) { .... } } SomeListener listener = ... Converter<String, String, Integer> converter = ... cache.addListener(listener, null, converter); So a user may get a ClassCastException at runtime if they retrieve those keys or values and they don't match. The only types that are specifically checked are the Key/Value types on both the KeyValueFilter and the Converter class and will throw a checked exception if they don't match. This example will have a checked exception, since we verify the types for those. Note the Filter has a type String for V but the Converter has Integer for V. Eg: KeyValueFilter<String, String> filter .. Converter<String, Integer, Integer> converter ... cache.addListener(listener, filter, converter); One thing this made me think of though is that we don't match the Cache variants with the filter and converter, this should be doable to enhance the hierarchy to ensure those types match the cache as well, but it might take a bit of refactoring to get it right. I have logged [1] to fix this. [1] https://issues.jboss.org/browse/ISPN-4079 On Thu, Mar 6, 2014 at 10:02 AM, Vladimir Blagojevic <vblagoje(a)redhat.com&gt; wrote: