Globale Variablen in Java?

[theTux]

Mitlerweile müsste das sogar mit allen Operatoren gehen. Empfehlenswert ist das trotzdem nicht...

[thana]

"Integer x = new Integer(42)", x ist nun ein Objekt und wird per Reference übergeben (wogegen 42 (oder eine Variable vom Typ int) per Value übergeben worden wäre)

Neinneinnein, in Java wird *NIE* irgendwas by-reference übergeben. Es wir *IMMER* *ALLES* by-value übergeben.
Im Falle von Objekten wird aber natürlich nur die Referenz auf das Objekt übergeben, das aber auch by-value!

[Lukul]

"Integer x = new Integer(42)", x ist nun ein Objekt und wird per Reference übergeben (wogegen 42 (oder eine Variable vom Typ int) per Value übergeben worden wäre)

Neinneinnein, in Java wird *NIE* irgendwas by-reference übergeben. Es wir *IMMER* *ALLES* by-value übergeben.
Im Falle von Objekten wird aber natürlich nur die Referenz auf das Objekt übergeben, das aber auch by-value!

Eben, ist wohl ein beliebter Fehler, der schon so manchen Leuten Prüfungen gekostet hat.

Habs grad mal ausprobiert: Zumindest in Java 1.6 funktioniert sowas hier problemlos:

Code: Alles auswählen

Integer i = 24;
Integer j = 27;
if (i <= j) {
     System.out.println("i <= j");
}


[theTux]

Zumindest in Java 1.6 funktioniert sowas hier problemlos:

Code: Alles auswählen

Integer i = 24;
Integer j = 27;
if (i <= j) {
     System.out.println("i <= j");
}


Das hat so keine Aussagekraft. Denn wenn der <=-Operator nicht überladen ist, werden die Speicheradressen verglichen. Und da du i vor j deklariert hast, wird i mit einiger Sicherheit auch vor j im Speicher stehen.

[fw]

Neinneinnein, in Java wird *NIE* irgendwas by-reference übergeben. Es wir *IMMER* *ALLES* by-value übergeben.
Im Falle von Objekten wird aber natürlich nur die Referenz auf das Objekt übergeben, das aber auch by-value!

Das ist mir völlig klar, da Coolcat das ja auch vor dir schon gesagt hat. Aber diese Kleinscheisserei ob das nun Call by Reference ist oder Call by Value wobei als Value eine Referenz übergeben wird... Ich glaube es war völlig klar was gemeint war...

[kb]

Es ist in sofern nicht egal (abgesehen von Prüfungsfragen), als dass man der übergebenen Variable nichts anderes zuweisen kannst, weil man eben keine Referenz übergeben kann!

--edit--
selbst wenn man Objekte übergibt (bei denen im Grunde ja wie gesagt nur die referenzierte Adresse übergeben wird), kann man nicht sagen "die Variable soll jetzt auf kein Objekt x sondern auf ein Objekt y zeigen".

[Tempest]

Ergänzung:

Code: Alles auswählen

public class Test {
   static Integer i;
   
   static void test(Integer i) {
      i++; // oder i = 1337; oder i = new Integer("0815"); etc..
   }
   
   public static void main(String[] args) {
      Test.i = 42;
      test(Test.i);
      System.out.println(Test.i);
   }
}

[Lukul]

Zumindest in Java 1.6 funktioniert sowas hier problemlos:

Code: Alles auswählen

Integer i = 24;
Integer j = 27;
if (i <= j) {
     System.out.println("i <= j");
}


Das hat so keine Aussagekraft. Denn wenn der <=-Operator nicht überladen ist, werden die Speicheradressen verglichen. Und da du i vor j deklariert hast, wird i mit einiger Sicherheit auch vor j im Speicher stehen.

Ach, echt?

Code: Alles auswählen

public class Test {
        public static void main (String[] args) {
            Thread j = new Thread();
            Thread k = new Thread();

            if (j <= k) System.out.println("");
        }
}


Code: Alles auswählen

ln@igemyvuci:~$ javac Test.java
Test.java:6: operator <= cannot be applied to java.lang.Thread,java.lang.Thread
            if (j <= k) System.out.println("");
                  ^
1 error


Ich wüsste nicht, dass man in Java Speicheradressen vergleichen könnte.

[mirko]

Ich wüsste nicht, dass man in Java Speicheradressen vergleichen könnte.

java kann aber auch gar nix

naja, ok - da java die komplette verwaltung des speichers mehr oder weniger geheim hält und der benutzer da eh nicht viel dran ändern kann, macht es auch keinen sinn, speicheradressen zu vergleichen...

[theTux]

Ach, echt?

Okay, ich gebe mich geschlagen - ausprobiert hatte ich das nicht.
Ich meine, es ging mal mit Java.

[mgla]

Es ist so das Java gewisste Integer (mit großem I) cached. ich meine das waren die von -128 bis +128. Vermutlich weil die am häufigstem verwendet werden.

Deshalb ist:

Code: Alles auswählen

(Integer) 15 == (Integer) 15


true, aber:

Code: Alles auswählen

(Integer) 150 == (Integer) 150


false.

[thana]

Es ist so das Java gewisste Integer (mit großem I) cached. ich meine das waren die von -128 bis +128. Vermutlich weil die am häufigstem verwendet werden.

Deshalb ist:

Code: Alles auswählen

(Integer) 15 == (Integer) 15


true, aber:

Code: Alles auswählen

(Integer) 150 == (Integer) 150


false.

Das hat nichts mit "caching" zu tun, sondern nur das Wiederverwenden von Objekten, bei denen die JVM Beweisen kann, dass es in Ordnung ist ein Objekt wiederzuverwenden.

ABER zu Beachten ist dabei stets die JLS.
so ist z.B. laut JLS

Code: Alles auswählen

"foo" == "foo"

immer true, wohingegen

Code: Alles auswählen

 new String ("foo") == new String ("foo")

immer false ergeben muss.
Darüber hinaus ist auch keines der im letzten Vergleich erzeugten Objekte identisch mit dem Objekt aus dem ersten Vergleich.

Das liegt auf der einen Seite Begründet darin, dass ein String immutable ist und auf der anderen Seite darin, dass new IMMER ein futschneues Objekt erzeugt.

Warum nun der vergleich von (Integer)150 mit ebenselben Ausdruck schiefläuft weiß ich nicht. Ich schätze das wird in irgendwelchen Optimierungen begründet sein.
Die genaueren Umstände werde ich mal in Erfahrung bringen. MICH interessierts jedenfalls

Ich meine, es ging mal mit Java.

Das ging übrigens nie. In der JLS steht eindeutig, dass die Argumente der relationalen Operatoren (im Kontext eines numerischen Vergleichs, man kann manche von ihnen ja auch zum Bit-Shifting verwenden) sich implizit in eine (numerischen) primitiven Typ casten lassen müssen.

[thana]

Es hat also Tatsächlich was mit Caching zu tun im Falle des Integer-Vergleichs.
Wird ein int zu einem Integer gecastet wird die Methode Integer#valueOf(int i)
Aufgerufen.
Im Sourcecode zu dieser Methode sieht man dann auch schnell, wieso der "Vergleich von 15" als Objekt erfolgreich ist, der von 150 aber nicht:

Code: Alles auswählen

    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);
    }


Also ein klassischer Fall von "da sollte man sich besser nicht drauf verlassen!"

[Tempest]

Die genaueren Umstände werde ich mal in Erfahrung bringen. MICH interessierts jedenfalls

JLS... [url=http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7]5.1.7 Boxing Conversion
[/url]