if ohne Wirkung

[Bouyo]

import java.util.Iterator;
import org.apache.commons.beanutils.BeanMap;

public class ObjectUtils {
          public void test(Object obj) {
    	      BeanMap  aBeanMap = new BeanMap(obj);
    	      
              for (Iterator i = aBeanMap.keySet().iterator(); i.hasNext();) {
            	  String property = (String) i.next();
            	  System.out.println("\"" + property + "\"");
            	  
            	  if ( property == "class" ) {
            		  System.out.println("Dieses ist class!");
            	  }
            }
       }
}

liefert mir für eine TestKlasse z.B. folgendes zurück

     "aFloat"
     "aInt"
     "aString"
     "class"
     "aDate"

Die Anweisung

            	  if ( property == "class" ) {
            		  System.out.println("Dieses ist class!");
            	  }

scheint keine Wirkung zu zeigen, weis jemand woran es liegen könnte?

 

[Crian]

equals()

 

[haui95]

if (property.equals("class")) {
    System.out.println("Dieses ist class!");
}

Der Vergleich mit Strings wird generell mit equals() gemacht, da beim Vergleichen von Strings mit Vergleichsoperatoren Probleme auftreten können.

 

[jstei001]

Genauer gesagt heißt dass: Bei Strings kann man nicht mit == vergleichen sondern muss die Methode euqals(String otherString) von der Klasse String nehmen. Es gibt noch EqualsIgnoreCase die berücksichtigt keine Groß- und Kleinschreibung.

 

[nillehammer]

Crian's Antwort etwas ausführlicher:

Prüfung auf Gleichheit bei Objekten mit equals(...)
Prüfung auf Identität bei Objekten mit ==.

Unterschied von gleich und identisch:
Gleichheit: Zwei zu vergleichende Entitäten sind genau dann gleich, wenn alle für die Gleichheit als relevant angesehenen Merkmale gleich sind.

Identität: Zwei zu vergleichende Entitäten sind dann identisch, wenn es sich um ein und die selbe Entität handelt.

 

[L-ectron-X]

FAQ: http://www.java-forum.org/top-fragen/1350-vergleichen-strings.html

 

[Solor]

Du könntest es auch mit compareTo() machen, das sähe dann so aus:

if (property.compareTo("class") == 0)
{
    System.out.println("Dieses ist class!);
}

 

[Spacerat]

Tja... wurde ja schon alles gesagt... obwohl da fällt mir noch 'ne Kleinigkeit ein, was Literale un Variablen angeht (könnte man direkt mit in die FAQ aufnehmen):
[c]"literal".equals(variable)[/c] statt [c]variable.equals("literal")[/c]. Wenn die Variable null ist, fliegt beim 2. eine NPE, beim 1. nicht. Ist zwar keine Pflicht, das 1. zu nehmen aber evtl. besser. Das 2. eignet sich hervorragend im Entwicklungsstadium einer Software, um Fehlern auf den Grund zu gehen, das 1. ist dagegen ein wenig mehr Absturzreduzierend.

 

[tfa]

[c]"literal".equals(variable)[/c] statt [c]variable.equals("literal")[/c]. Wenn die Variable null ist, fliegt beim 2. eine NPE, beim 1. nicht. Ist zwar keine Pflicht, das 1. zu nehmen aber evtl. besser. Das 2. eignet sich hervorragend im Entwicklungsstadium einer Software, um Fehlern auf den Grund zu gehen, das 1. ist dagegen ein wenig mehr Absturzreduzierend.

Ich würde von Variante 1 fast immer abraten. Das macht nur Sinn, wenn man wirklich weiß, dass null für variable ein legaler Wert ist (normalerweise möchte man aber null-Werte vermeiden). In allen anderen Fällen soll die NPEx möglichst sofort fliegen. Variante 1 ist dann nicht "absturzreduzierend" sondern fehlerverschleiernd.

 

[Spacerat]

Ich würde von Variante 1 fast immer abraten. Das macht nur Sinn, wenn man wirklich weiß, dass null für variable ein legaler Wert ist (normalerweise möchte man aber null-Werte vermeiden). In allen anderen Fällen soll die NPEx möglichst sofort fliegen. Variante 1 ist dann nicht "absturzreduzierend" sondern fehlerverschleiernd.

Genau deswegen sagte ich das mit der "Entwicklungsphase". In dieser stellt man entweder fest, dass Nullwerte legal sind oder man merzt sie mit Variante 2 erstmal aus. Zur Distribution kann man dann getrost Variante 1 verwenden. Anwender der Software können dann nicht meckern, dass da unvorhergesehene Sachen passieren, weil sie diskret vor eine Wand fahren. Andernfalls müsste sich immer der Programmierer rechtfertigen, und herausfinden, wie der Anwender genau dort Fehler hinbekommt, wo eigentlich jeder Usecase durchgespielt wurde. API nicht gelesen? Reflections, JNI oder sonst was benutzt? Und der Anwender erwartet dann auch noch sein "täglich BugFix". :lol:

 

[tfa]

Genau deswegen sagte ich das mit der "Entwicklungsphase". In dieser stellt man entweder fest, dass Nullwerte legal sind oder man merzt sie mit Variante 2 erstmal aus. Zur Distribution kann man dann getrost Variante 1 verwenden.

Allein diese Annahme ist schon ziemlich weltfremd. Was soll "die Entwicklungsphase" sein? Es wird immer entwickelt. Selbst wenn die Software produktiv ist gibt es Service-Releases, Bugfixes usw. Man kommt ja auch nicht auf die Idee, Unittests wegzuschmeißen, nur weil man glaubt, aus der Entwicklungsphase raus zu sein.
Selbst wenn man diese "Phasen" abgrenzen könnte, ist es wohl recht unsinnig anzunehmen, man würde für die "Distribution" eben mal den ganzen Quelltext durcharbeiten, um aus Variante 2 Variante 1 zu machen. Was du vielleicht meinst sind asserts.
Außerdem stellt man während der Entwicklung nicht "fest, ob Nullwerte legal sind". Das sollte schon irgendwo definiert und dokumentiert sein -- wenn man weiß, was man tut.

Anwender der Software können dann nicht meckern, dass da unvorhergesehene Sachen passieren, weil sie diskret vor eine Wand fahren.

Ich bin mir nicht sicher, ob ich den Satz richtig verstehe. Du willst den Anwender die NullpointerException ersparen und das Programm weiter laufen lassen?

Andernfalls müsste sich immer der Programmierer rechtfertigen, und herausfinden, wie der Anwender genau dort Fehler hinbekommt, wo eigentlich jeder Usecase durchgespielt wurde. API nicht gelesen? Reflections, JNI oder sonst was benutzt? Und der Anwender erwartet dann auch noch sein "täglich BugFix".

Tja, wenn das Programm nicht funktioniert, wird sich wohl irgend jemand verantworten und erbarmen müssen, den Bug zu fixen. Wer kann das wohl sein? Dann ist mir eine NPEx mit Stacktrace und Zeilennummer sofort lieber -- als in zwei Monaten unerklärliche Report-Ergebnisse, weil Daten falsch berechnet wurden.

 

[Spacerat]

Das diese Einstellung weltfremd ist, ist mir schon klar, aber es gibt schlimmeres. Ich sag's mal so. Andere haben diese Exceptions noch viel lieber, schliesslich sagen sie ja nicht nur etwas darüber aus, was schief gelaufen ist, sondern vor allem auch wo. Eine Stelle, an der das Programm definitiv korrumpierbar ist.
Also ja, ich würde das Programm weiterlaufen lassen. Ne' Bug-Meldung wird's ja wohl kaum geben, wenn alle immer wüssten, was sie tun.