This is not exactly Java's fault. Generic type information is just lost during runtime. Java/JSF/EL does not run during compiletime, but during runtime. All it sees during runtime is a Set, not a Set<Long>.
When JSF sets submitted input values as bean properties, it retrieves them in first place as String as that's the default return type of request.getParameter(), which JSF is using under the covers to obtain request parameters. As long as no converter is specified, JSF will set those submitted String values unconverted in the Set via reflection. This is basically what is happening "under the covers":
package com.stackoverflow.q14521882;
import java.lang.reflect.Field;
import java.util.Collection;
import java.util.HashSet;
import java.util.Set;
public class Test {
private Set<Long> set = new HashSet<Long>();
public static void main(String[] args) throws Exception {
Test test = new Test();
Field field = test.getClass().getDeclaredField("set");
Object object = field.get(test);
if (object instanceof Collection) {
((Collection) object).add("string");
}
System.out.println(test.set.iterator().next().getClass()); // CCE!
}
}
It would work when you was using Long[] instead of Set<Long>, but given that it's a Set in first place, you'd like to hold unique values only and the Long[] is therefore likely not an option. In order to solve it, you need to explicitly specify a Converter in the input component. You can use JSF builtin LongConverter for this, which has a converter ID of javax.faces.Long:
<h:selectManyListbox ... converter="javax.faces.Long">