Sounds good. I'd have to dig further to determine if a fix really makes sense from a functional point of view... based on my limited understanding, I'm not sure that TypeHelper.normalize would ever get called under supported scenarios. For bean validation it seems to be called only when (improperly) using a validator with a parameterized type.

But I agree about fixing it for the sake of correctness. The added benefit may be that fixing it could also result in a better indication of where the user went wrong. As it is, the root of the problem in our project was completely obscured. If it can't be easily fixed due to other use-cases (I don't know where else TypeHelper is used...?) maybe it makes sense to add a check somewhere along the line to throw an exception if the user has introduced a validator with a parameterized type.

Or even something as simple as...

	private static <K, V> Map<K, V> normalize(Map<K, V> map) {
		// TODO: will this cause an infinite loop with recursive bounds?

		for ( Entry<K, V> entry : map.entrySet() ) {
			K key = entry.getKey();
			V value = entry.getValue();

			// Avoid infinite loop. If key = value, that entry is already normalized. 
			if (!key.equals(value)) {
				while ( map.containsKey( value ) ) {
					value = map.get( value );
				}
			}

			map.put( key, value );
		}

		return map;
	}

But I'm not sure what change would be appropriate in the grander scheme.