TreeSet exception bei add

[Marco_adv]

Hallo ich habe ein Problem mit meinem Treeset und zwar möchte ich ich dieser Mehtode:

	private void loadRights(String userId) throws SQLException {
		userRights = new TreeSet<RightsForUser>();
		Iterator i = connection.getAuthorisation(userId).iterator();
		while(i.hasNext()) {
			RightsForUser right = (RightsForUser) i.next();
			userRights.add(right);
		}
	}

die ausgelesenen Rechte des Users in einen Treeset speichern, dazu habe ich die quals methode in RightsForUser implimentiert diese sieht wie folgt aus:

public boolean equals(Object rightsforUser) {
		if (this == rightsforUser) {
			return true;

		}
		if (!(rightsforUser instanceof RightsForUser)) {
			return false;
		}
		RightsForUser userRights = (RightsForUser) rightsforUser;

		if ((this.getLevel().equals(userRights.getLevel()))
				&& (this.getRight().equals(userRights.getRight()))) {
			return true;
		}
		return false;
	}

nun bekomme ich eine classcast exception un der Methode RightsForUser kann mir jemand weiter helfen ? gruß Marco

 

[MatthiasKnorr]

Wo genau entsteht denn die Exception?
Gib mal vor dem Cast die Klasse des Objekts aus, welches du casten möchtest.

Grüße,
Matthias

 

[byte]

Du verhinderst durch das Überschreiben der equals ja nicht, dass auch Objekte eines andere Typs als RightsForUser in das Set mit aufgenommen werden. Du musst also entweder ein typisiertes Set<RightsForUser> verwenden (Java SE 5 oder höher) oder Du musst in der loadRights explizit prüfen, ob das vom Iterator gelieferte Objekt auch vom Typ RightsForUser ist, bevor Du castest.

Edit: OK, hab nicht richtig hingeguckt. Du verwendest ja ein typisiertes Set, aber verwendest den alten Iterator. Du brauchst einen Iterator<RightsForUser> oder musst halt entsprechend die Überprüfung mit instanceof vor dem Casten machen.

 

[Marco_adv]

Kann es sein dass die Class RightsForUser Comparable implementieren muss?

 

[byte]

Das macht bei TreeSet durchaus Sinn, hat aber prinzipiell erstmal nichts mit einer ClassCastException zu tun.

 

[Marco_adv]

Doch nun bekommt er keine ClassCastException mehr es wird aber nur ein Object in den TreeSet geschrieben also muss ich nicht mit equals arbeiten sondern mit compareTo oder?

 

[Wildcard]

Das macht bei TreeSet durchaus Sinn, hat aber prinzipiell erstmal nichts mit einer ClassCastException zu tun.

throws ClassCastException if the specified object cannot be compared with the elements currently in the set.

 

[MatthiasKnorr]

Versteh ich nicht.
Wieso kommt jetzt keine Exception mehr nur weil die Objekte comparable sind.
Die Exception kann doch eigentlich nur in Zeile 6 auftreten.

 

[Marco_adv]

Ja nur weil die Objecte comparable sind kommt nun keine Exception mehr. Nun versuche ich aber comarable noch zu implementieren, damit ich prüfen kann ob das objekt schon im TreeSet steht doch da weiß ich nicht ganz weiter nur dass result 0 equals bedeutet und aloles andere nicht gleich. kann mir hier noch jemand helfen?

 

[Wildcard]

Die Exception kann doch eigentlich nur in Zeile 6 auftreten.

Nö. In ein TreeSet dürfen nur Comparable Objekte eingefügt werden wenn kein Comparator übergeben wird.

 

[MatthiasKnorr]

Richtig, die Sau ruft die Methode compare auf. Unglaublich.

 

[byte]

In ein TreeSet dürfen nur Comparable Objekte eingefügt werden wenn kein Comparator übergeben wird.

Achso, dachte er nimmt dann die "Natural Order", wenn man keinen angibt. Aber macht natürlich Sinn so.

 

[Wildcard]

Die natural order muss ja bestimmt werden, und das wird mit dem Comparable Interface gelöst :wink:
Allerdings hätte man das wirklich etwas expliziter hinschreiben können.

 

[Marco_adv]

kann man ja nicht wissen aber auf jedefall funktioniert alles danke für eure antworten

 

[byte]

Die natural order muss ja bestimmt werden, und das wird mit dem Comparable Interface gelöst :wink:
Allerdings hätte man das wirklich etwas expliziter hinschreiben können.

Ich hätte jetzt gedacht, er ordnet dann im Zweifelsfall nach Hash oder so, aber ergibt ja auch keinen Sinn, wenn man drüber nachdenkt.


Imo sollte Sun aber echt gewissen "Constraints" in der Javadoc besser hervorheben. Gibt genug Beispiele, wo imo wichtige Informationen irgendwo im Text verschwindet. Zum Beispiel könnte man in Vector mit riesigen blinkenden Buchstaben drüber schreiben: Ich bin böse! Benutz mich nur mit Java Version 1.0 oder Legacy Code.

 

[Wildcard]

Vector ist so schlimm ja nicht. Synchronisiert ist nicht grundsätzlich was schlechtes und macht auch nicht so wahnsinnig viel an der Performance aus.
Problematisch ist der Vector nur wenn man ihn nicht über das Interface anspricht, sondern über elementAt usw. weil er dann nicht mehr so einfach austauschbar ist.

 

[byte]

Ich meine mal gelesen zu haben, dass Vector nicht nur wegen der Synchronisation langsamer sein soll. Bin mir über die Quelle aber nicht mehr sicher, war glaube ich in Thinking in Java.

 

[Wildcard]

Ich weiß nicht wie er früher ausgesehen hat, und ich weiß nicht wie er heute implementiert ist, aber ich bin davon überzeugt das er mittlerweile nahezu identisch mit ArrayList ist (bis auf die Synchronisierung).