ACHTUNG: dies ist nur eine Testantwort für SlaterB, mit der wir verswuchen, einen Fehler nachzustellen !!!
EDIT: Ah, da haben wir es schon! Es passiert durch das Kopieren zwischen neue JAVA-Tags!! Wieder was gelernt (ist in anderen Foren nicht immer so, da wird wohl auch manchmal nur der reine Text kopiert!
Reicht Dir das so ??
Gruß
Klaus
Hi SlaterB,
so ich teste es jetzt nochmal (hier ein einfaches CTRL-V) :
if(getMatrikelnummer() == stud.getMatrikelnummer()){
Es sieht hier in Editor so aus, dass die Zeile mit den vorherigen Java-Tags eingefügt wurde …
Java Code:
[LEFT]
[ol]
[li]if(getMatrikelnummer() == stud.getMatrikelnummer()){[/li][/ol]
[/LEFT]
So nun habe ich den Text mit CRTL-V zwichen neue JAVA-TZags eingefügt . sieht hier gleich aus !
Jetzt werde ich mal speichern und dann Editieren …
Gruß
Klaus
allein dass du farblich kopieren kannst, auch außerhalb der Java-Tags das obere Beispiel,
ist schon bemerkenswert genug,
wenn dann innerhalb der Java-Tags beim Editieren noch was schiefgeht ist das ein weiteres Thema,
aber für mich gerade sekundär 
na, ich kann es eh nur weiterreichen
if(getMatrikelnummer() == stud.getMatrikelnummer()){
Hi SlaterB,
stimmt 
BTW: ich nutze hier den FF V22.0!
Ich glaube mich jetzt auch dunkel zu erinnern, dass ich dann beim Editieren versucht hatte, die vorhandene Textzeile noch in die JAVA-Tags zu kopieren, da der Eintrag für mich „nicht korrekt“ aussah, so wie ich es von JF oder auch Tutorials.de gewohnt bin
Und dann kam beim Versuch, die HTML-Tags rauszulöschen iwie Schrott heraus :mad:
Na ja, werde mir fürs nächste Mal merken :eek:
tschüss
Klaus
OFFTOPIC:
habe ja leider Deine „bösen“ Beiträge, die zur Löschung Deines Kontos bei JF führten nicht mehr lesen können … war esw wirklich so schlimm ?? :o)
[QUOTE=vfl_freak;23287]OFFTOPIC:
habe ja leider Deine „bösen“ Beiträge, die zur Löschung Deines Kontos bei JF führten nicht mehr lesen können … war esw wirklich so schlimm ?? :o)[/QUOTE]
Ich glaub das würden wir alle mal gerne wissen 
ich vermute es war die allzu deutliche Formulierung der eben unschönen, vielleicht nicht allzu deutlichen Wahrheit,
dass die angemeldeten User keine Werbung sehen werden, sorgenlos weiter arbeiten, für den Werbe-Admin die Arbeit leisten sollen,
während wehrlose Neu-Gäste/ google-Sucher mit der Werbung abgezockt werden
Java Code:
[LEFT]
[ol]
[li][QUOTE=Marco13]Test Test Test [COLOR=red]Test[/COLOR][/QUOTE][/li][/ol]
[/LEFT]
Test
der zweite Code ist dann fatal, jede Klammer eine Color:
[QUOTE=Marco13]Java Code:
[LEFT]
[ol]
[li][QUOTE=Marco13;24068]Test Test Test [COLOR=red]Test[/COLOR][/QUOTE]
[/li][/ol]
[/LEFT]
Test[/QUOTE]
weiter immer schlimmer
edit: doch nicht
sieht ja ganz gut aus, nur im Quellcode viele [ COLOR ]
Das ist ungültigerweise verallgemeinert. Man kann nur genau dann den HashCode cachen, wenn das Objekt (oder zumindest die für den HashCode und die Gleichheit relevanten Felder) immutable ist.
Sobald sich ein nicht-immutable-Feld ändert, welches in die Berechnung des HashCode eingeht, ändert sich logischerweise nämlich auch der HashCode. Und in jedem Setter den gechachten HashCode zu invalidieren lohnt sich wahrscheinlich nur in wenigen Ausnahmefällen.
@SlaterB : Vielleicht sollte man hier nochmal nass durchwischen
wenn sich Felder, der Hashcode selber ändert, hat man ganz andere Probleme als Neuberechnen oder Einsparung,
wenn das Objekt schon mit altem Hashcode in eine HashMap usw. eingetragen ist…
in einer Aufbauphase wie Konstruktor ist das ja unumgänglich,
ab dem Zeitpunkt aber, ab dem man sich einen hashcode zum Objekt vorstellt, sollte dieser und die zugehörigen Felder möglichst gleich bleiben
Ja, die Diskussion hatten wir in einem anderen Forum schonmal vor langer, langer Zeit Nichtsdestotrotz bin ich damals zu dem Entschluss gekommen, dass es durchaus legitim ist, volatile Objekte (ist das das Gegenteil von Immutable-Objects?) mit einer hashCode-Methode zu versehen. Die Konsequenzen, die aus der Objektänderung entstehen, hat der Benutzer des Objektes dann zu tragen.