equals() und ==

[tuttle64]

Als SCJP-Student sind mir die Unterschiede von equals() und == wohl bekannt. Beim Testen habe ich folgenden Code laufen lassen:

public class IntegerExampe {

	public static void main(String[] args) {
		Integer i1 = 5;
		Integer i2 = 5;
		Double d1 = 1.0;
		Double d2 = 1.0;
		System.out.println(i1==i2);
		System.out.println(d1==d2);
	}
}

Nun, i1==i2 liefert true, aber d1==d2 liefert false, Float liefert ebenfalls false. Kann mir jemand auf die Sprünge helfen, weshalb der Vergleich mit String, Integer, Byte etc. true liefert aber mit Double und Float false? Korrekterweise sollten Vergleiche auf den Inhalt stets mit überschriebener equals()-Methoden erfolgen. Dennoch hätte ich gerne eine Begründung für mein false-Problem.

 

[BlackViruZ]

eine Range an Integer Objekten (-127 bis 127 wars glaub ich) wird von der JVM in einem Pool gehalten, wenn du ein neues Integer Objekt in dieser Range durch auto boxing erstellst wird statt dessen das Objekt aus dem Pool genommen.

Bei Double und Float wird das nicht gemacht.

#EDIT:
Der pool ist -128 bis 127 (beides inclusive)

Autoboxing ist nicht die einzige Variante in der das Objekt aus dem Pool kommt, aber bei einer expliziten neuerstellung von einem Integer Objekt via new Operator wird eine neue Instanz erstellt und der pool ignoriert. (dachte das könnte noch ganz gut zu wissen sein..)

 

[tuttle64]

eine Range an Integer Objekten (-127 bis 127 wars glaub ich) wird von der JVM in einem Pool gehalten, wenn du ein neues Integer Objekt in dieser Range durch auto boxing erstellst wird statt dessen das Objekt aus dem Pool genommen.

Bei Double und Float wird das nicht gemacht.

Genau, das ist es! Vielen Dank. Wenn ich die Stelle im Buch finde, werde ich den ganauen Wortlaut nachliefern.

 

[SlaterB]

und Strings direkt im Quellcode werden vom Compiler gecacht,
werden sie mehrfach aus einem Textfeld, Netzwerk oder System.in gelesen oder char für char zusammengebaut sind sie normalerweise nicht ==

    /**
     * Returns a <tt>Integer</tt> instance representing the specified
     * <tt>int</tt> value.
     * If a new <tt>Integer</tt> instance is not required, this method
     * should generally be used in preference to the constructor
     * {@link #Integer(int)}, as this method is likely to yield
     * significantly better space and time performance by caching
     * frequently requested values.
     *
     * @param  i an <code>int</code> value.
     * @return a <tt>Integer</tt> instance representing <tt>i</tt>.
     * @since  1.5
     */
    public static Integer valueOf(int i) {
	final int offset = 128;
	if (i >= -128 && i <= 127) { // must cache 
	    return IntegerCache.cache[i + offset];
	}
        return new Integer(i);
    }

 

[musiKk]

und Strings direkt im Quellcode werden vom Compiler gecacht

So ähnlich. Stringliterale werden in den Constantpool einer Klasse geschrieben. Zur Laufzeit müssen gleiche Literale durch gleiche Instanzen repräsentiert werden. Für dynamisch erzeugte Strings gilt dies nicht. Man kann eine solche Instanz aber durch [c]intern()[/c] erhalten.