Android Generischer Unterschied

[Spacerat]

Hallo
Ich verstehe folgenden Umstand nicht:

// Fehler: java.util.List<Class<SomeObject>> can not be cast to java.util.Collection<Class<?>>
new Test((Collection<Class<?>>) Arrays.asList(SomeObject.class));

// Fehler: the Constructor java.util.List<Class<SomeObject>> doesn't exist
new Test(Arrays.asList(SomeObject.class));

class Test {
  Test(Collection<Class<?>> collection) {
    //...
  }
}

In der Oracle-Standard VM funktioniert beides anstandslos, beim obersten bekommt man sogar noch die Warnung, dass der Cast überflüssig ist. In Android erweitert das List-Interface ebenfalls das Collection-Interface und "Arrays.asList()" gibt auch eine solche List zurück. Woher also kommen diese Fehlermeldungen? Ich tappe im Dunkeln, please Help.

 

[schlingel]

Es liegt nicht an der Signatur sondern an der Auflösung der Generizität.

Da die Hotspot VM von Oracle ganz eine andere VM ist als Googles Dalvik VM kommt es in solchen speziellen Gebieten zu Ungereimtheiten. Ich habe wegen solchen Fehlern schon einmal die JSON-Lib wechseln müssen. (Testcase von Jackson funktionierte in der Hotspot VM und nicht im Android System ...)

Als Workaround könntest du hier in der Signaturen eine Raw-Class angeben und keine Class<T>. Dann umgehst du die Generizitätinkompatibilitäten (wahrscheinlich).

 

[Landei]

Casten unter Angabe generischer Parameter ist sowieso sinnlos - im besten Fall überflüssig, und im schlechtesten Fall irreführend.

 

[SlaterB]

war lange einer meiner Lieblingssprüche,
angesichts

public class Test {
    public static void sort(Baumstamm2[] arr)  {
        List<?> l = null;
        l.add(""); // geht nicht
        ((List<String>)l).add(""); // geht
    }
}

verzichte ich aber lieber darauf, wobei man hier auch ne passende Variable deklarieren könnte

 

[Spacerat]

Es liegt nicht an der Signatur sondern an der Auflösung der Generizität.

Da die Hotspot VM von Oracle ganz eine andere VM ist als Googles Dalvik VM kommt es in solchen speziellen Gebieten zu Ungereimtheiten. Ich habe wegen solchen Fehlern schon einmal die JSON-Lib wechseln müssen. (Testcase von Jackson funktionierte in der Hotspot VM und nicht im Android System ...)

Als Workaround könntest du hier in der Signaturen eine Raw-Class angeben und keine Class<T>. Dann umgehst du die Generizitätinkompatibilitäten (wahrscheinlich).

Ich hab' da doch bereits Raw-Types, deswegen wundert's mich ja. Wenn ich den Konstruktor auf
[c]Test(Collection<? extends Class<?>> collection)[/c] ändere, geht's. Nur wenn ich dann Caste, trifft das zu, was Landei sagt und wenn ich's lasse bleibt 'ne Type-Safety-Warnung.

 

[schlingel]

Collection<Class> wäre der RAW-Type von Collection<Class<T>>. Und Typ-Safety Warning ist egal wenn du dafür sorgst, dass der aufrufende Context keine Gefährdung darstellt. Dieses Warning ist viel zu sensibel, weswegen es ja auch in Java 7 nur noch auf der Seite aufscheint in der eine Library geschrieben wird und nicht mehr auf der aufrufenden Seite.

 

[Landei]

Collection<Class> wäre der RAW-Type von Collection<Class<T>>.

Collection

wäre der Raw-Type von

Collection<Class<T>>

. Ein Raw-Type enthält niemals Typparameter.

 

[schlingel]

Schon klar, ich hab mich auch auf das Class bezogen da ich dort den Schuldigen für die Inkompatibilität vermute.

 

[Spacerat]

Okay... Raw bedeutete für mich bisher immer unspezifiziert und das <?> gehörte halt dazu.