Java infering wrong type of a typed HashSet [duplicate]

问题

Possible Duplicate:
ClassCastException when calling TreeSet<Long>.contains( Long.valueOf( someLongValue ) )

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.

回答1:

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

回答2:

The first problem is that you ask for a new Iterator each time you step into the while. The second problem is that Iterator is generic so you better do something like this:

Iterator<Long> cylinderIter = cylinderIds.iterator();

while(cylinderIter.hasNext()) {
    cylinderIter.next() // ...
    // do something
}

The third problem is that I can't see where you happen to populate that Set. I can help you more if you show us the code.

回答3:

Without to see your code I could answering that something is changing the type of your set:

Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parameterized types (which are technically known as raw types). The main disadvantages are that parameter type information is not available at run time, and that automatically generated casts may fail when interoperating with ill-behaved legacy code. There is, however, a way to achieve guaranteed run-time type safety for generic collections even when interoperating with ill-behaved legacy code.

The generics article of oracle documentation explain you better.

Try this code for see when the problem is happening:

Set<Long> s = Collections.checkedSet(new HashSet<Long>(), Long.class);

来源：https://stackoverflow.com/questions/14521882/java-infering-wrong-type-of-a-typed-hashset

标签

java

jsf

generics