Warnung zu Generics (Java 1.6)

[Onkel Hatti]

Hallo Alle.

Ich entwickele in Eclipse und habe ein Problem mit den Generics.

package de.hk.test;

import java.util.Enumeration;
import javax.swing.tree.DefaultMutableTreeNode;

public class Test2Class {

	public static void main(String[] args)
	{
		DefaultMutableTreeNode root=new DefaultMutableTreeNode("root");
		for(int i=0; i<10;i++)
		{
			DefaultMutableTreeNode node=new DefaultMutableTreeNode("node"+i);
		}

		Enumeration e=root.children();
		while(e.hasMoreElements())
		{
			DefaultMutableTreeNode n=(DefaultMutableTreeNode)e.nextElement();
		}
	}

}

Wenn ich das so mache, geht es, aber Eclipse warnt mich bei "Enumeration e=root.children();":

"Enumeration is a raw type. References to generic type Enumeration<E> should be parameterized"

OK, dachte ich mir, ist ja klar, Enumeration sollte mit dem, was es zu erwarten hat, parametrisiert werden.

package de.hk.test;

import java.util.Enumeration;
import javax.swing.tree.DefaultMutableTreeNode;

public class Test2Class {

	public static void main(String[] args)
	{
		DefaultMutableTreeNode root=new DefaultMutableTreeNode("root");
		for(int i=0; i<10;i++)
		{
			DefaultMutableTreeNode node=new DefaultMutableTreeNode("node"+i);
		}

		Enumeration <DefaultMutableTreeNode>e=root.children();
		while(e.hasMoreElements())
		{
			DefaultMutableTreeNode n=e.nextElement();
		}
	}

}

Das geht auch, aber nun warnt mich Eclipse:

"Type safety: The expression of type Enumeration needs unchecked conversion to conform to Enumeration<DefaultMutableTreeNode>"

Wo ist mein Gedankenfehler? Wie bekomm ich die Warnung weg? (Ausser durch "@SupressWarnings")

Hatti

 

[Wortraum]

root.children() gibt eine Aufzählung ohne Parametertyp zurück, und die soll in eine Aufzählung mit Parametertyp DefaultMutableTreeNode gesteckt werden; die Warnung ist also berechtigt. Da kannst Du gar nichts machen, außer diese Warnung zu unterdrücken.

 

[0x7F800000]

Generics = 1.5
Swing = 1.2

gottverdammt, wie haben die es bloß gewagt Generics in eine Sprache nicht von anfang an einzuplanen? ;(

Sehe da jedenfalls auch keine Alternative, imho müsstest du einfach alles explizit casten und alle warnungen mit @SupressWarnings plattmachen. Und ärgere dich über diesen altertümlichen schrott nicht zu sehr: damit kann man auch irgendwie leben, aber sorge einfach dafür, dass du nicht selbst solchen typunsicheren Kram fabrizierst

 

[Marco13]

Da die Frage damit vermutlich beantwortet ist, ein bißchen ""off""-Topic (lohnt sich dafür ein eigener Thread?). Was ist mit "Swing 2.0" - mit Generics? (GEHT das überhaupt? Ich glaub' ja nicht ???:L (zumindest nicht "konsequent"))

 

[0x7F800000]

Da die Frage damit vermutlich beantwortet ist, ein bißchen ""off""-Topic (lohnt sich dafür ein eigener Thread?). Was ist mit "Swing 2.0" - mit Generics? (GEHT das überhaupt? Ich glaub' ja nicht ???:L (zumindest nicht "konsequent"))

Es ist ja wohl nichts neues, dass ich solche Bestrebungen prinzipiell befürworte. Wieso das nicht möglich sein sollte ist mir erstmal unklar. Besser als so wie es jetzt ist geht es sicherlich: wenn dieses Swing-dingens nicht mehr mit Objects und Vector's (sogar ohne <>-Klammer^^) um sich werfen würde, und sich nicht von tonnen von integers ernähren würde, wären wohl einige hunderttausend leute glücklicher. So wirkt es überholt, verrostet und verstaubt, und mit der Zeit wird's nicht besser. :autsch:

 

[Marco13]

Natürlich könnte mal, als einfaches, plakatives Beispiel, eine ComboBox machen wie

JComboBox<String> comboBox = new JComboBox<String>();

und dort dann ohne casten mit "getItem" direkt einen String rauskriegen. Aber die größte Schwierigkeit sehe ich bei Listenern - zumindest hatte ich mal versucht, in einem bestimmten Zusammenhang Listener und Generics zu kombinieren, und das endete in einem gezippten Ordner mit dem Namen [c]....(backup) 007 Listener may not be type safe - PERIOD - Get over it.zip[/c].

Bevor jetzt die Hinweise kommen, dass das "doch ganz einfach ist"...

class JComboBox<T> {
    void addListener(Listener<T> listener) {...}
}
interface Listener<T> {
    void changed(Event<T> event);
}
class Event<T> {
    T getItem() { ... }
}

ja, das ist es, im einfachsten Fall, und wenn man einige praktische Aspekte außer acht läßt. Irgendwie lief es eben darauf raus, dass man bei einem Event (der zur Laufzeit geworfen wird) einfach nicht mehr die nötigen Typinformationen mitbekommt - und spätestens bei event.getSource() geht sowieso nichts mehr. Notfalls kann ich nochmal versuchen, die Gründe kurz und präzise zusammenzufassen, aber ... so eine kurze Aussage ist zeitaufwändig...

 

[0x7F800000]

[c]....(backup) 007 Listener may not be type safe - PERIOD - Get over it.zip[/c].
[...]
Notfalls kann ich nochmal versuchen, die Gründe kurz und präzise zusammenzufassen, aber ... so eine kurze Aussage ist zeitaufwändig...

Echt, so aussichtslos? :lol:
Nein, brauchst jetzt natürlich diese sinnlose Experimente nicht erneut aufzurollen, wenn du es nicht hinbekommen hast, dann ist es ein gutes Anzeichen dafür, dass das Problem nicht so trivial ist, wie es auf den ersten Blick erscheint, das glaube ich dir erstmal auch so.
Wie es speziell bei den Listenern aussieht überlege ich mir etwas später nochmal, wenn ich mich wieder in swing eingelesen habe, bisher ist es in diesen Semesterferien nicht der Fall, bin eh ein wenig aus der Übung