Innerer Type einer generischen Collection herausfinden?

[sirbender]

Hi,

Ich will den Innerer Type einer generischen Collection herausfinden. Ich habe folgendes:

List<Integer> list = new LinkedList<Integer>();

Nun haette ich gerne eine Methode getInnerType(list); die mir das Class-Object der Inneren Klasse zurueckgibt.


Das muss doch moeglich sein, oder?

Danke!

 

[SlaterB]

zur Laufzeit hast du einen Programmcode der Form
List list = new LinkedList();
es ist also kein Staubkorn dieser Info vorhanden, daher nicht herauszufinden,

Generics ist ein reiner Spass zur Kompilierzeit, damit dich der Compiler warnt, falls du andere Objekte als Integer speicherst,


nur wenn die Liste nicht leer ist, könntest du dir den Typ der enthaltenen Objekte anschauen

 

[tfa]

zur Laufzeit hast du einen Programmcode der Form
List list = new LinkedList();
es ist also kein Staubkorn dieser Info vorhanden, daher nicht herauszufinden,
Generics ist ein reiner Spass zur Kompilierzeit, damit dich der Compiler warnt, falls du andere Objekte als Integer speicherst,

Für 99% der Fälle ist das korrekt, aber doch nur die halbe Wahrheit. Man kann tricksen. Sowas funktioniert z.B.:

public class Test<T> {

    @SuppressWarnings("unchecked")
    public Test() {
        Class<T> clazz = (Class<T>) ((ParameterizedType) getClass()
            .getGenericSuperclass()).getActualTypeArguments()[0];

        System.out.println("Mein Typparameter ist: "+clazz);
    }

    public static void main(String... args) {
        new Test<Integer>(){};
        new Test<Thread>(){};
        new Test<Exception>(){};
    }
}

-->
Mein Typparameter ist: class java.lang.Integer
Mein Typparameter ist: class java.lang.Thread
Mein Typparameter ist: class java.lang.Exception

Ist zwar sehr hässlich und eine sinnvolle Anwendung habe ich noch nicht finden können.

 

[SlaterB]

na hier legst du ja auch anoyme innere Klassen an,
dass neue Klassen die Info enthalten ist etwas verständlicher

hättest dann gleich mit LinkedList machen können, dann wäre es deutlicher:

public class Test {

	public static void main(String[] args) throws Exception {
		List<Integer> list = new LinkedList<Integer>() {
		};

		Class clazz = (Class) ((ParameterizedType) list.getClass().getGenericSuperclass())
				.getActualTypeArguments()[0];

		System.out.println("Typparameter ist: " + clazz);
	}

}

 

[byte]

Ergänzung:

List<Integer> list = new LinkedList<Integer>() {};
Class clazz = list.getClass();
while (!(clazz.getGenericSuperclass() instanceof ParameterizedType)) {
        clazz = clazz.getSuperclass();
    }
Class genericClass = (Class) ((ParameterizedType) clazz.getGenericSuperclass()).getActualTypeArguments()[0];

 

[SlaterB]

hmm, bei mir gibts ne Exception,
die while-Schleife ist nicht nötig, da List selber ja die GenericSuperclass ist,
klappt das bei dir?

 

[tfa]

Das klappt nur, wenn der Parameter in der Oberklasse definiert ist (daher der Trick mit den {} hinter dem Konstruktoraufruf).
Deswegen ist der Nutzen ziemlich beschränkt.

 

[byte]

hmm, bei mir gibts ne Exception,
die while-Schleife ist nicht nötig, da List selber ja die GenericSuperclass ist,
klappt das bei dir?

Arg, war ein Fehler beim Kopieren. Habs korrigiert.

 

[Guest]

hmm, bei mir gibts ne Exception,
die while-Schleife ist nicht nötig, da List selber ja die GenericSuperclass ist,
klappt das bei dir?

Arg, war ein Fehler beim Kopieren. Habs korrigiert.

jo, danke. Ich muesste also die Java-List Klassen ueberschreiben und dafuer sorgen, dass sie alle waehrend des Erstellens eines List-Objektes den ParameterizedType speichern?


Was ich machen wollte:

1. Per Reflection den Konstruktor einer Klasse holen
2. Dieser hat eine Liste (die auch parameterisiert ist - zumindest im Sourcecode
3. Eine parameterisierte Liste erstellen und mit Dummy-Werten vom Richtigen Type fuellen (nur wie krieg ich den Typ raus?)
4. Konstruktor mit dieser Liste aufrufen und ein Objekt erstellen.


Das geht wohl niemals, selbst nicht mit den abenteuerlichsten Hacks, hab ich das richtig verstanden?

Danke trotzdem!

 

[SlaterB]

> Ich muesste also die Java-List Klassen ueberschreiben und dafuer sorgen, dass sie alle waehrend des Erstellens eines List-Objektes den ParameterizedType speichern?

das klingt leicht falsch, du kannst auch bei eigenen Klassen nicht einbauen, dass der Typparameter gespeichert wird
(außer, indem ein entsprechendes Objekt oder das zugehörige Class-Objekt hinterlegt wird)

die Beispiele beziehen sich vielmehr auf das Anlegen von Subklassen mit einem ganz bestimmten fest angegeben generischen Typ,
LindekList<Integer> als anoyme innere Klasse mag die Info 'Integer' fest verdrahtet haben,
aber damit kannst du keine LinkedList<String> mehr erstellen


> Das geht wohl niemals, selbst nicht mit den abenteuerlichsten Hacks, hab ich das richtig verstanden?

sag niemals nie ,
aber nach dem bisherigen Wissensstand in diesem Thread siehts so aus, ja

 

[Guest]

> Ich muesste also die Java-List Klassen ueberschreiben und dafuer sorgen, dass sie alle waehrend des Erstellens eines List-Objektes den ParameterizedType speichern?

das klingt leicht falsch, du kannst auch bei eigenen Klassen nicht einbauen, dass der Typparameter gespeichert wird
(außer, indem ein entsprechendes Objekt oder das zugehörige Class-Objekt hinterlegt wird)

die Beispiele beziehen sich vielmehr auf das Anlegen von Subklassen mit einem ganz bestimmten fest angegeben generischen Typ,
LindekList<Integer> als anoyme innere Klasse mag die Info 'Integer' fest verdrahtet haben,
aber damit kannst du keine LinkedList<String> mehr erstellen


> Das geht wohl niemals, selbst nicht mit den abenteuerlichsten Hacks, hab ich das richtig verstanden?

sag niemals nie ,
aber nach dem bisherigen Wissensstand in diesem Thread siehts so aus, ja

Sauerei...diese Type Ereasure Generics ist aber auch nutzlos. Wuerde mich ja ueber die zusaetzliche Komplexitaet nicht beschweren, wenn man wenigstens aehlich viele Vorteile hat...aber so...

Waren die zu faul oder warum hat Sun den Weg der Type Ereasure gewaehlt? Gab es keine Alternativen?

 

[Tobias]

Type Erasure sorgt dafür, dass alter Code < 1.5 mit Code >= 1.5 zusammenarbeiten kann.

mpG
Tobias

 

[Guest]

Es gibt zu "ich möchte zur Laufzeit den Typ eines Objektes wissen" fast immer sauberere Alternativen, genau dafür ist ja Polymorphie und dynamisches Binden von Methodenaufrufen an Methoden da.

 

[SlaterB]

die Anwendung wurde ja genannt, da wird man kaum was schöneres machen können

wan immer irgendwas allgemein dynamisch passieren soll, wie bei Hibernate und seinen Beans,
dann kann man mit all den guten OO-Methoden einpacken

Reflection oder gar nicht oder noch schlimmeres (XML-Dateien, ..)