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">