Collections.emptySet() und triärer Operator

[Andreas29]

Hi Leute,

folgende Zeile Code ist ja vollkommen legal und wird vom Compiler auch korrekt interpretiert:

Set<String> s = Collections.emptySet();

Nur warum schmeißt folgende Zeile dann einen Compilerfehler?

Set<String> s = anotherSet.isEmpty() ? Collections.emptySet() : new HashSet<String>()

Der Compilerfehler lautet:
cannot convert from Set<capture#1-of ? extends Object> to Set<String>

Kann mir das bitte irgendwer erklären?

Danke und Grüße,
Andreas

 

[Landei]

Geht's so?

Set<String> s = anotherSet.isEmpty() ? Collections.<String>emptySet() : new HashSet<String>();

 

[musiKk]

Generisch funktionierts.

Aber nochmal zum ursprünglichen: Der Fehler tritt irgendwie nur im Eclipse-Compiler auf. Der Sun-Compiler nimmts mit einer Warning:

Test.java:6: warning: [unchecked] unchecked conversion
found   : java.util.Set
required: java.util.Set<java.lang.String>
                Set<String> s = (args.length == 0) ? Collections.emptySet() : ne
w HashSet();
                                                   ^
1 warning

So wirklich erklären kann ichs mir aber im Moment auch nicht.

 

[SlaterB]

Ternärer Operator, liefert zwei Typen, also wird auf den höchsten gemeinsamen gecastet,
in diesem Fall Set<?>

 

[Andreas29]

Hi,

danke für die Antworten.

@SlaterB:
Das habe ich noch nicht so ganz verstanden. Ich meine, es ist klar, Collections.emptySet liefert ein Set<?> zurück, das ist klar. Und new HasSet<String> liefert ein HashSet für String-Objekte, auch klar. Und der gemeinsame parent ist natürlich Set<?>. Das ist auch klar, nur warum kann er dann im ersten Fall ohne Murren ein Set<?> in ein Set<String> speichern? Wenn er das intern castet, warum tut er dass dann beim trenären Operator nicht? Das verstehe ich noch nicht...

Grüße,
Andy

 

[Illuvatar]

Dass die

Set<String> s = Collections.emptySet();

Version funktioniert, nennt sich generic type inference. Collections.emptySet gibt nämlich kein Set<?> zurück, sondern ein Set<T>. In der Version ohne den ternären Operator ist der Compiler so intelligent, selbst den richtigen generischen Parameter (<String>) für die Methode zu wählen. In der anderen Version offensichtlich nicht - scheint mir eine kleine Schwachstelle zu sein. Da die type inference hier nicht greift, sieht der Compiler das tatsächlich als Set<?> und damit wird der ganze Ausdruck zu einem Set<?>. Landeis Schreibweise scheint die beste Lösung zu sein.

siehe auch: Effective Java, Items 1 und 27