Bug in der JVM?

[landi]

ICh komme wieder auf meinen Punkt zurück.

Wieder die Klasse Punkt:

public class Punkt{	
	public double x;
	public double y;

                public Punkt(double x, double y){
                        this.x=x;
                        this.y=y;
                }
}

und meine main-Klasse

public class Appl{
	public static void main(String[] args){
		Punkt p1 = new Punkt(3.0,4.0);
		p1.y=5.0;
	}
}

Wenn ich es kompiliere funktioniert es auch, wie erwartet.

Nun mache ich folgendes:
Ich verändere die Punkt-Klasse und mache das y zu private. Dann kompiliere ich nur die Klasse Punkt!!!.
Nun starte ich die main-Klasse und es läuft. WARUM?????

Wenn ich die main-Klasse neu kompiliere geht es verständlicherweise nicht, so wie es eben auch sein sollte. Hat jemand vielleicht eine Idee.

Sorry wenn ich so seltsame Fragen habe, aber die stellen meine Lehrgangsteilnehmer und dann kommt man, auch wenn die Dinge trivial erscheinen, erst einmal ins grübeln.

Landi

 

[mikachu]

gute frage... java eben :lol:

 

[thE_29]

Weil das hier genauso geht

Punkt.java

public class Punkt{   
   private double x;
   private double y;

                public Punkt(double x, double y){
                        this.x=x;
                        this.y=y;
                }

                public String toString()
                {
                    return "x: " + x + " y: " + y;
                }
}

PunktTest.java

import java.lang.reflect.Field;
public class PunktTest{
   public static void main(String[] args) throws Exception{
      Punkt p1 = new Punkt(3.0,4.0);
      Field f = p1.getClass().getDeclaredField("y");
      f.setAccessible(true);
      f.setInt(p1,5);
      
      //p1.y=5.0; <- alter Weg
      //System.out.println(p1.y); <- alter Weg
      System.out.println(p1);
   }
}

Es ist aber trotzdem net fein das es geht, es könnte wenigstens ne Access Exception werfen, weil wenn man das y komplett rauslöscht, kommt wenigstens ein NoSuchFieldError (also wenigstens da kommt ne Fehlermeldung..)

Tjo, java eben :bae: (habs mit java 1.5.0_02 probiert und da gehts auch..)

 

[mikachu]

also haben die javanesen bei der implementierung der JVM wieder mal zu viel an sicherheit gespart !

 

[Murray]

also haben die javanesen bei der implementierung der JVM wieder mal zu viel an sicherheit gespart !

Das könnte man natürlich zur Laufzeit alles prüfen, aber das wird vermutlich aus Gründen der Effizienz nicht gemacht. Krassere Beispiele gibt es da, wo der Compiler Inlining betreibt, den Code also in einer anderen Klassen dupliziert

public class T1 {

	public static final String CONST = "xy";
}

public class T2 {

	public static void main( String[] args) {
	
		System.out.println( "T1.CONST=" + T1.CONST);
	}
}

Wenn man jetzt T1.CONST auf private setzt und nur T1 übersetzt, ändert das nichts an der Ausgabe von T2.
Wenn man den Wert von T1.CONST ändert und nur T1 übersetzt, ändert das auch nichts an der Ausgabe von T2.
Wenn man CONST komplett entfernt und nur T1 übersetzt, ändert das immer noch nichts an der Ausgabe von T2.

Dieses Verhalten kann man aus Sicherheitsgründen wohl kritisieren; ohne das Inlining oder mit zusätzlichen Konsistenzprüfungen zur Laufzeit würde man aber Performance verlieren.

 

[byte]

also haben die javanesen bei der implementierung der JVM wieder mal zu viel an sicherheit gespart !

Sorry, aber das ist Blödsinn. Das Ganze nennt sich Inline Caching und ist kein Bug sondern ein Feature. :bae: Dabei werden Daten über Methode und Klasse direkt beim Aufrufer inline (also direkt im erzeugten Code) gespeichert. Es findet also eine Optimierung statt, denn beim Ausführen muss dadurch nicht erst eine (erneute) Methodensuche stattfinden.

Für den Entwickler bedeutet das natürlich, er muss bei Änderungen im Quellcode nicht nur die geänderte Quelldatei neu compilieren, sondern auch alle Dateien, die mit dieser Datei in Beziehung stehen. Für gewöhnlich kompiliert man halt einfach alles neu. Dann ensteht auch nicht ein solche inkonsistentes Verhalten.

 

[mikachu]

ich hab ja auch nicht gesagt, dass es wirklich so ist, sondern ich hab nur eine vermutung angestellt, da ich mir das auch nicht erklären konnte... aber danke für die saubere erläuterung deinerseits

MfG mika