问题描述
Please see the screenshot for the problem:
It seems an entry in the Typed Set cylinderIds
is suddenly of type String
- but how did that happen?
The bean is used from within a JSF page, but I always thought that the type system in Java should prevent this ... Any idea what is going wrong here?
Using 1.7.0_06 64 Bit on Windows 7, the application is run within a JBoss 7.1.0 on the same Java version.
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">
这篇关于Java推断类型HashSet的错误类型的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!