Interpreter-Fehler Null?

[Xandaros]

Hallo!
Ich bezeichne mich selbst zwar nicht als Anfänger. fühle mich aber gerade wie einer, deswegen poste ich hier.

Folgendes:
Ich habe eine abstrakte Klasse A, die ungefähr so aufgebaut ist:

public abstract class A
{
	public A()
	{
		this.onInit();
	}

	public abstract void onInit();
}

Und eine Klasse B, die A erweitert mit einer ArrayList als feld darin:

public class B extends A
{
	public static ArrayList<C> liste = new ArrayList<C>(15);

	public B()
	{
		super();
	}

	public void onInit()
	{
		liste.add(new C());
	}
}

In Zeile 12 von Klasse B bekomme ich eine NullPointerException.
Durch eine simple if-Abfrage habe ich bereits bestätigt, dass liste an der Stelle null ist.

Jetzt meine große Frage: Warum?

 

[Gast2]

Nein, der Fehler tritt so bei dem Code mit Sicherheit nicht auf.

 

[eRaaaa]

Felht da nicht ein extends A bei der Klasse B ?

 

[Xandaros]

Felht da nicht ein extends A bei der Klasse B ?

Das ist zwar richtig, ist aber nicht das Problem

Nein, der Fehler tritt so bei dem Code mit Sicherheit nicht auf.

Ich würds auch nicht glauben, wenns nicht so wäre -_-

Ich geb euch mal den echten Code, ist aber wahrscheinlich schwerer zu lesen:

public abstract class NeoScreen extends GenericPopup
{
	//Hier fehlen natuerlich noch ein paar sachen
	public NeoScreen(SpoutPlayer player)
	{
		width = player.getMainScreen().getWidth();
		height = player.getMainScreen().getHeight();
		
		this.player = player;
		
		this.onInit();
	}

	//Und hier sind auch noch ein paar unwichtige methoden

	public abstract void onInit();
}

public class GuiNPC extends NeoScreen
{
	private ArrayList<Label> messages = new ArrayList<Label>(15);
	
	//Weitere deklarationen

	public GuiNPC(SpoutPlayer player)
	{
		super(player);
	}

	@Override
	public void onInit()
	{
		addButton(0, (width - 73)/2, (height + 166)/2, 75, 10, "Close");
		for (int i = 0; i < 15; i++)
		{
			Label label = addLabel(0, 0, "");
			label.setX((width - GenericLabel.getStringWidth(label.getText())) / 2);
			label.setY(height / 6 + i * 10);
			messages.add(label); //Hier kommt die exception
		}
	}

	//Weitere methoden
}

Achja, der fehler kommt beim Instanzieren von B bzw. GuiNPC

 

[Gast2]

wird messages irgendwo mal mit nem neuen Wert belegt? Mach messages mal final.

 

[eRaaaa]

Hier ist messages / deine Liste ja auch nicht statisch, das ist ein ganz anderes Beispiel jetzt. Du rufst hier schon Methoden auf (init) und dein Objekt ist noch nicht einmal instanziiert 100%. Das ist unschön!

 

[Xandaros]

wird messages irgendwo mal mit nem neuen Wert belegt? Mach messages mal final.

Ne, wirds nicht. Ist final, kein Compiler-fehler und immer noch NullPointerException.

 

[Gast2]

eRaaaa hat schon die Lösung gepostet!
Das Objekt ist noch nicht vollständig initialisiert wenn du die Methode onInit aufrufst. Als Faustregel: im Konstruktor nie nicht-finale Methoden aufrufen. Speziell wenn die Klasse abgeleitet wird.

 

[Xandaros]

Hier ist messages / deine Liste ja auch nicht statisch, das ist ein ganz anderes Beispiel jetzt.

Ouch, da bin ich mit einem anderen Feld durcheinander gekommen... sorry!

Du rufst hier schon Methoden auf (init) und dein Objekt ist noch nicht einmal instanziiert 100%. Das ist unschön!

Oh verdammt...
Wie kann ich onInit denn direkt nach dem initialisieren aufrufen?
Ich möchte nicht, dass man die Methode jedes mal von Hand aufrufen muss...

 

[Gast2]

Du kannst dir eine Factory Methode schreiben:

public static NeoScreen createGuiNPC(SpoutPlayer player) {
  NeoScreen instance = new GuiNPC(player);
  instance.init();
  return instance;
}

 

[irgendjemand]

ich hab da auch noch was anzumerken

public class B extends A
{
	public static ArrayList<C> liste = new ArrayList<C>(15);

	public B()
	{
		super();
	}

	public void onInit()
	{
		liste.add(new C());
	}
}

AUA ... das macht man so nicht ...

deklarationen können auch im static-context stehen ...

initialiserungen MÜSSEN in methoden/konstruktoren stehen ...

auch in diesem beispiel KANN "liste" NULL sein ... wenn der compiler das "new List<?>()" erst hinter den call von "onInit()" schiebt ...
was durch den call von "super()" immer der fall sein wird ... da "super()" grundsätzlich IMMER zu erst kommen muss ...

wenn nun durch diesen super-call eine methode gecallt wird die ein objekt verändern soll ... was so noch garnicht exisitiert *da die initialisierung erst NACH super() kommen würde* ist das objekt *oder besser die referenz* NULL

ums mal zu veranschaulichen

deinen pseudo-code würde die VM wie folgt übersetzen :

public class B extends A
{
	public static ArrayList<C> liste;

	public B()
	{
		super();
		liste = new ArrayList<C>(15)
	}

	public void onInit()
	{
		liste.add(new C());
	}
}

die call-reihenfolge wäre aber : B() -> super() -> A() -> onInit() -> liste.add() -> liste=new List<?>
und aus genau diesem grund bekommst du die NPE

 

[...ButAlive]

ich hab da auch noch was anzumerken

AUA ... das macht man so nicht ...

deklarationen können auch im static-context stehen ...

initialiserungen MÜSSEN in methoden/konstruktoren stehen ...

auch in diesem beispiel KANN "liste" NULL sein ... wenn der compiler das "new List<?>()" erst hinter den call von "onInit()" schiebt ...

AUA das tut aber mal richtig weh.

Du weißt schon wann statische Felder initialisiert werden? Dann wenn die Klasse geladen wird, und das ist garantiert bevor der Konstruktor aufgerufen wird, denn erst nach dem Laden weiß die VM welche Konstruktoren es gibt.

Natürlich hast du recht dass Initialisierungen in Methoden stehen müssen. Aber der Compiler ist so nett und macht aus:

class Foo{
  String bar = "Test";
}

class Foo{
 String bar;  
 void <init>(){
    bar = "Test";
  }
}

Und aus:

class Foo{
  static String bar = "Test";
}

class Foo{
 static String bar;  
 static void <clinit>(){
    bar = "Test";
  }
}

 

[Spacerat]

Da hakt es aber gewaltig...
Was "irgendjemand" da sagt, ist nur teilweise richtig und für ...ButAlive gilt das selbe.
nicht primitive Klassenkonstanten werden unter Umständen erst bei ihrer ersten Verwendung in Konstruktoren instanziert. Wenn man sie nicht explizit in der Klasseninitialisierungs-Methode ([c]static {}[/c]) initialisiert, bekommt man möglicherweise solche Probleme, wie der TO (er ruft eine Klassen-Methode auf).
Im Übrigen lassen sich (vorzugsweise bei Singletons) Konstruktoren auch schon bei der Initialisierung der Klasse aufrufen... das ist böse. XD

 

[...ButAlive]

nicht primitive Klassenkonstanten werden unter Umständen erst bei ihrer ersten Verwendung in Konstruktoren instanziert.
Wenn man sie nicht explizit in der Klasseninitialisierungs-Methode ([c]static {}[/c]) initialisiert, bekommt man möglicherweise solche Probleme, wie der TO (er ruft eine Klassen-Methode auf).

Da sagt die Spezifikation aber etwas anderes:

A static initializer declared in a class is executed when the class is initialized (§12.4.2). Together with any field initializers for class variables (§8.3.2), static initializers may be used to initialize the class variables of the class.

Chapter*8.*Classes

Wobei dieser Code:

public class Foo
{
    static String bar = "HALLO";
}

und dieser Code:

public class Foo
{
    static String bar;
    static{
        bar = "HALLO";
      }
}

den selben ByteCode erzeugen.

public class Foo extends java.lang.Object{
static java.lang.String bar;

static {};
  Code:
   0:	ldc	#10; //String HALLO
   2:	putstatic	#12; //Field bar:Ljava/lang/String;
   5:	return

public Foo();
  Code:
   0:	aload_0
   1:	invokespecial	#17; //Method java/lang/Object."<init>":()V
   4:	return

}

Das Problem das der TO hat tritt in seinem abstrakten Beispiel gar nicht auf. Im "richtigen" Code den er als 2. gepostet hat, ist die Liste nicht

static

und dann kommt das beschriebene Problem.

 

[Spacerat]

Da sagt die Spezifikation aber etwas anderes:
Chapter*8.*Classes

So viel anders ist das gar nicht. Der statische Initializer muss implementiert sein, damit das zutrifft. Ich bin auf diese JVM-Meise auch schon reingefallen. Solange dort nicht "final" steht und static nicht implementiert wurde, instanziert die JVM on demand (hast's in deinen Codebeispielen doch erklärt).

 

[...ButAlive]

Irgendwie reden wir aneinander vorbei. Wenn man eine statische Variable instanziert ohne einen static initzialzier Block zu schreiben, erzeugt der Compiler einen. Man muss diesen nicht explizit angeben. Dieser wird dann ausgeführt wenn die Klasse instanziert wird. Das ist der Fall, wenn der Classloader sie zum ersten mal lädt.

Bevor man den Konstruktor einer Klasse aufrufen kann, ist garantiert die Klasse schon geladen.

 

[Spacerat]

Irgendwie reden wir aneinander vorbei.

Mag sein.

Bevor man den Konstruktor einer Klasse aufrufen kann, ist garantiert die Klasse schon geladen.

Geladen ja, aber initialisiert? Nicht unbedingt. Konstrukte wie

class AnyClass
{
  static AnyClass instance;

  static
  {
    instance = new AnyClass();
  }

  AnyClass()
  {
    // some code
  }
}

funktionieren zwar, aber man muss genau wissen, was man wann tut, sonst kommt der Hangman. Z.B. braucht man sich nicht einfallen lassen, innerhalb des Konstruktors auf "instance" zugreifen zu wollen. Eigentlich sollten solche Konstrukte verboten werden, damit man einen Mechanismus hinbekommt, der sicherstellt, dass eine Klasse vollständig initialisiert wurde, noch bevor der Konstruktor aufgerufen werden kann. Wie will man denn sonst wissen, wann eine Klasse spätestens initialisiert ist bzw. sein sollte? Wie gesagt: Die von der VM automatisch eingefügten initializer werden irgendwo mitten bei der ersten Instanzierung aufgerufen.