Gast reto.koenig Geschrieben February 9, 2013 at 21:27 Geschrieben February 9, 2013 at 21:27 Wäre es möglich die equals() und die hashCode() Methode noch (auf Device.java) zu implementieren? Dann können die Devices auch in einem HashSet verwaltet werden. Ich kann auch gerne dabei helfen... wie schon gesagt, ich hab's einfach nicht so mit github Grüsse Reto Zitieren
AuronX Geschrieben February 10, 2013 at 11:19 Geschrieben February 10, 2013 at 11:19 Grundsätzlich sollte das bereits jetzt schon gehen oder? Wenn ich mich recht entsinne dann ist die Standardimplementierung von Object doch ein Referenzvergleich oder? Das würde lediglich bedeuten, dass du Probleme bekommst, wenn du für die gleiche UID zwei Device-Objekte anlegst. Ich würde behaupten, dass du dadurch auch von Seiten der TF-Bindings Probleme bekommst. Spätestens bei Verwendung zweier Devices mit gleicher UID in unterschiedlichen Threads können die Bindings für nichts mehr garantieren. Oder übersehe ich gerade einen anderen Vorteil des Überschreibens von hashCode und equals? Ansonsten würde ich es vermutlich über die interne (int/long) UID implementieren. Zitieren
Gast reto.koenig Geschrieben February 10, 2013 at 17:35 Geschrieben February 10, 2013 at 17:35 Ok, ich sehe, es kommt überhaupt nicht gut, wenn ein Device zweimal als Device-Objekt instanziert wird... In der abstrakten Klasse Device.class wird beim Instanzieren eines Device-Objekt stets folgendes aufgerufen: ipcon.devices.put(this.uid, this); Da bringt es auch nix mehr, wenn man dann nachfragt, ob zwei Device-Objekte äquivalent sind... Denn das ältere Objekt ist aus dem Rennen... soz. zerstört. Dann frage ich mich aber, ob es überhaupt erlaubt sein sollte, in einer JVM-Instanz ein Objekt zweimal als Device-Objekt instanzieren zu dürfen? Zitieren
AuronX Geschrieben February 10, 2013 at 19:28 Geschrieben February 10, 2013 at 19:28 Dann frage ich mich aber, ob es überhaupt erlaubt sein sollte... Denke schon. Sagen wir ich lege mir ein Device an, verliere dann alle Referenzen (das alte Objekt lebt aber noch wegen ausstehender GC) und möchte mir ein frisches Device zum Weiterarbeiten anlegen. Das würde jetzt schiefgehen. Dann bräuchte ich plötzlich einen expliziten Mechanismus zum Freigeben von Devices, um dieses neue Problem zu umgehen. Ich denke dadurch wird das Fehlerpotenzial eher größer als kleiner. Viele Grüße Jan Zitieren
Gast reto.koenig Geschrieben February 10, 2013 at 20:18 Geschrieben February 10, 2013 at 20:18 Nur ums schnell noch zu sagen: Ich jammere hier auf hohem Niveau. Das Framework an sich ist wirklich toll! Bloss: Nachdem ich alle Referenzen verloren habe wäre es doch eigentlich gut sie wieder erlangen zu können, statt sie als 'side effect' dem GC dem Frass vorzuwerfen?! Denn andere Teile des Programms arbeiten ja vielleicht noch mit dieser Instanz... So z.B. wenn sie sich als Listener bei dieser Instanz eingetragen hatten. Der Ort, an dem diese Referenzen noch zu finden wären, um sie wieder aufzugreifen, ist die IPConnection. Dort gibt's die HashMap<Long,Device>, bei der ich per UID das Device wieder holen könnte. Aber diese Map ist mit Visibility: default/package deklariert. In dem Falle vielleicht ein public Device getDevice(String uid) in der IPConnection? Ich möchte ja bloss, dass ich nicht unbemerkt eine an sich laufende Instanz 'abhänge', weil ich eine neue Instanz erzeuge... Zitieren
AuronX Geschrieben February 10, 2013 at 20:45 Geschrieben February 10, 2013 at 20:45 Naja... grundsätzlich bist du halt dafür verantwortlich die Referenzen die du selbst brauchst auch selbst zu behalten Was ich geschrieben habe war eh unsinn. Erst wenn die IPConnection weg ist kommt der hungrige GC und isst alles auf. Weil solange hat die IPConn ja noch ne Referenz. Das ist auch gut so ^^ Ich halte es auf jeden Fall für vertretbar, dass man nur ein Objekt pro Stackelement haben darf. Eine Methode zum Erlangen des Devices aus der IPConnection finde ich nicht vollkommen verwerflich, würde sie aber (wäre es mein Framework) nicht zur Verfügung stellen. Wie ich als IPConnection meine Devices verwalte (z.B. dass ich sie problemlos per UID wiederfinden kann) würde ich verbergen. Zitieren
Gast reto.koenig Geschrieben February 10, 2013 at 20:59 Geschrieben February 10, 2013 at 20:59 Gut! Bzgl. des 'Singleton' Ansatz sind wir uns klar einig, denn das sehe ich nun auch so. Bloss, dass eine verlorengegangene Instanz nicht wieder zu beschaffen ist, das finde ich nicht so gut... (Memory-Leakage / Side-Effect). In der IPConnection die HashTable private zu deklarieren finde ich natürlich auch klar gut. Aber vielleicht wäre es wirklich nett, wenn die IPConnection die Referenz auf Anfrage (wie auch immer die dann aussieht) zurückgeben könnte?! Ich schreibe mir nun mal einen Wrapper, der das Singleton-Verhalten der einzelnen Device-Instanzen für mich abbildet. Bloss.... ist ein wenig doppelspurig. Aber was sind schon ein paar 32bit-Referenzen Redundanz ;-) Im übrigen: Danke für den konstruktiven Dialog mit mir als Novizen! Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.