Generic Bug?

[TheWhiteShadow]

Ich hab die Methoden keySet und values zu einer Feldvariablen(HashMap) delegiert.
Beim Zugriff von außen ging der Typ-Parameter flöten.

Beispiel:

class Klasse {
	private HashMap<String, Integer> map;

	public Set<String> keySet() {
		return map.keySet();
	}

	// ...
	for (String key : this.keySet()) // Kein Problem
}
// ...
Klasse klasse = new Klasse();
for (String key : klasse.keySet()) // Error: cannot convert from element type Object to String

Die von Eclipse angezeigte Methodensignatur bestätigt den Fehler. Außerhalb der Klasse ist der Typ weg.
Sieht für mich in erster Linie wie ein Bug aus.

 

[Sonecc]

Kann das nicht nachvollziehen, bei mir funktioniert alles normal

 

[Michael...]

Kann ich bei mir nicht nachvollziehen (Eclipse Indigo, JDK 1.6)

 

[Spacerat]

Dito... funzt so wie es soll. Eclipse Juno mit Java7

 

[TheWhiteShadow]

Ok, habs mit meinem Minimalbeispiel noch mal getestet und gesehen, dass es bei mir auch geht.
Hab beim Kürzen das Typargument übersehen, was wohl eine Rolle spielt.

Die delegierende Klasse benötigt ein Typargument und muss in einer Raw-Variablen gehalten werden.
Allerdings ist die HashMap und die Delegate-Methode völlig unabhöngig vom Typ-Argument der Klasse selbst.

Korrektur:

class Klasse<E> {
	private HashMap<String, Integer> map;

	public Set<String> keySet() {
		return map.keySet();
	}

	// ...
	for (String key : this.keySet()) // Kein Problem
}
// ...
Klasse klasse = new Klasse<Object>();
for (String key : klasse.keySet()) // Error: cannot convert from element type Object to String

btw: (Eclipse Helios, JDK 1.6) (Eclipse Indigo, JDK 1.7)

 

[Spacerat]

Es läuft auch ohne Typargument

class Klasse {
	Map<String, Integer> map;

	public Set<String> keys() {
		return map.keySet();
	}
}

public class Test {
	public static void main(String[] args)
	{
		Klasse k = new Klasse();
		for(String s : k.keys()) {
			
		}
	}
}

 

[Gast2]

Brauchst du zwingend den Raw type?

Klasse<?> klasse = new Klasse<Object>();

So würde das gehen.

 

[TheWhiteShadow]

Ich weiß, dass es ohne Typargument läuft.
Ich habs ja noch mal nachgeprüft.

Dass das Beispiel ohne Typargument auskommt ist mir auch klar.
Aber mit Argument tritt der Bug auf und darum gehts mir.

Ich Weiß auch mitlerweile wie ichs umgehen Kann.

Trotzdem danke.

 

[faetzminator]

Ich Weiß auch mitlerweile wie ichs umgehen Kann.

IDE auf Updates überprüfen? Crappy JDK wegwerfen? ...

 

[mvitz]

Also ich kann das mit folgendem Code auch unter diversen JDKs (1.5.0_22, 1.6.0_35 und 1.7.0_05) nachvollziehen:

import java.util.HashMap;
import java.util.Map;
import java.util.Set;

public final class Test<T> {

    private final Map<String, Integer> map = new HashMap<String, Integer>();

    public Test() {
        map.put("Foo", 1); 
        map.put("Bar", 2); 
    }   

    public Set<String> keys() {
        return map.keySet();
    }   

    public static void main(String[] args) {
        final Test t = new Test<Object>();
        for (String s : t.keys()) {
            System.out.println(s);
        }   
    }   
}

Ändert man jedoch Zeile 19 nach:

final Test<Object> t = new Test<Object>();

funktioniert es.

 

[faetzminator]

mvitz, warum typisierst du [c]Test[/c]?

 

[Spacerat]

@faetzminator: Die Frage wollte ich auch grad' stellen.

@TheWhiteShadow: Wenn's bei dir nur mit Typearguments geht, dann liegt's wohl an deinem speziellen Code, also dem des realen Projekts. Ich würd' das aber nicht als Bug bezeichnen.

 

[maki]

...
Ändert man jedoch Zeile 19 nach:

final Test<Object> t = new Test<Object>();

funktioniert es.

Irgendwer hat in diesem forum mal einen Link zu einem Google tech talk gepostet, da wurde dieseer "Effekt" erläutert:
Die Klasse Test nimmt einem gen. Typen entgegen, nutzt ihn aber nicht, soweit, so gut.
Wenn man ihn aber weglässt, wirft der Compiler alle Generics über Bord und arbeitet munter ohne weiter...

Das ist kein Compiler Bug o.ä., liegt am Code, dieser sollte korrigiert werden.

 

[Gast2]

mvitz, warum typisierst du [c]Test[/c]?

Weil die Klasse des TOs auch typisiert ist. Das ist ja grad sein Problem.
Benutzt man den Raw type werden alle Generics entfernt, und dann krachts beim keySet.

 

[Spacerat]

@EikeB: Gut zu wissen... wo kann man das nachlesen? :rtfm:

Aber BTW.: Die Klasse des Eingangsposts war nicht typisiert.

 

[faetzminator]

Weil die Klasse des TOs auch typisiert ist.

Schau dir nochmals sein Beispiel aus dem ersten Post an... Typisiert hat er es nur, um den Fehler (?) zu beheben.

 

[FArt]

Ich schätze mal es handelt sich hier um einen Effekt im Zusammenhang mit "Type Erasure".
Typparameter werden durch die Klasse aus der Boundsklausel ersetzt. Wenn keine da ist, werden sie durch Object ersetzt.

 

[TheWhiteShadow]

Also verwirft der Kompiler bei einem Raw-Typ nicht nur meinen Typen sondern auch alle beinhaltenden Typen (Hier die, der HashMap und des Sets) ?

Also mach er auch aus

public Set<String> keySet()

->

public Set keySet()

.

Schau dir nochmals sein Beispiel aus dem ersten Post an... Typisiert hat er es nur, um den Fehler (?) zu beheben.

Jep, war falsch. Ist mir ausversehen beim Vereinfachen der Original-Klasse passiert.
Hab nicht gewusst, dass es am Typen der Klasse Klasse lag.^^

 

[faetzminator]

Das klärt einiges. Zusammenfassend kann man sagen: Wenn die Klasse gar nicht typisiert ist, kein Problem. Wenn die Klasse typisiert ist, man den Typen aber nicht kennt, sollte man [c]<?>[/c] o.ä. verwenden.

 

[Gast2]

Schau dir nochmals sein Beispiel aus dem ersten Post an... Typisiert hat er es nur, um den Fehler (?) zu beheben.

Und im Post #5 hat er sich korrigiert. Das der Code aus dem ersten Post funktioniert steht ja außer Frage.