Pourquoi ca plante ?

Laurent Bossavit

29/09/2003 à 16:59

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

J'irais voir du côté des règles d'appel des constructeurs, et notamment
l'ordre de priorité entre l'appel des constructeurs et l'initialisation
des variables d'instance. Je peux me tromper, car je n'ai pas analysé le
code en détail, mais ça ressemble à un problème que j'ai précédemment
traité dans ce groupe:

http://urrhidar.notlong.com/

Voir aussi la JLS:
http://java.sun.com/docs/books/jls/second_edition/html/jTOC.doc.html

Laurent
http://bossavit.com/

Bruno

29/09/2003 à 18:21

dans l'article , Armel HERVE à
a écrit le 29/09/2003 14:43 :

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

ca plante avec l'exeption :
java.lang.NullPointerException
at com.test.TestNull$InnerClass.access$0(TestNull.java:11)
at com.test.TestNull$InnerClass$AbstractClassImpl.getLength
(TestNull.java:18)
at com.test.TestNull$AbstractClass.<init>(TestNull.java:25)
at com.test.TestNull$InnerClass$AbstractClassImpl.<init>
(TestNull.java:16)
at com.test.TestNull$InnerClass$AbstractClassImpl.<init>
(TestNull.java:16)
at com.test.TestNull$InnerClass.<init>(TestNull.java:13)
at com.test.TestNull.<init>(TestNull.java:8)
at com.test.TestNull.main(TestNull.java:32)
Exception in thread "main"

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
InnerClass() {
AbstractClassImpl zz = new AbstractClassImpl();
}

private class AbstractClassImpl extends AbstractClass {
int getLength() {
return TestNull.this.test.length();
}
}
}

private abstract class AbstractClass {
public AbstractClass() {
System.out.println("getLength()=" + getLength());

la tu utilises getLenght() de AbstractClassImpl avant que l'objet soit
completement instancié. non?

je ne pense pas que cela soit lié au classes internes.

}

abstract int getLength();
}

public static void main(String[] args) {
TestNull testNull1 = new TestNull();
}
}
</code>

--
Bruno Causse
http://perso.wanadoo.fr/othello

Nicolas Delsaux

30/09/2003 à 08:08

Le 29.09 2003, Armel HERVE s'est levé(e) et
s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

Si le code que tu utilises ressemble à ça, t'es vraiment dans la merde.

Parce que comme paquet de nouilles moche et avec des dépendances
croisées, on ne fait pas mieux.

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

On va essayer, avec une petit cinématique du code ...

Démarrage.
Appel au constructeur de TestNull, qui initialise la chaîne, puis appelle
le constructeur de InnerClass (déja, c'est super moche, mais bon...).
Le constructeur de InnerClass appelle à son tour (sans conserver de
références (super)) celui de AbstractClassImpl.
AbstractClassImpl dérivant de AbstractClass, le constructeur de cette
classe est appelé. Dans ce constructeur, on appelle la méthode abstraite
getLength.
Cette méthode est implémentée dans AbstractClassImpl (encore heureux !)
et retourne théoriquement la valeur de TestNull.test.length().
Or ici, on est toujours dans le constructeur de TestNull. Il n'est donc
pas possible d'utiliser le pointeur this dans cette méthode (puisque le
this n'existe pas encore réellement). Et donc, test n'existe pas, et
test.length renvoie une NullPointerException.
CQFD.
Mon conseil ? Evites ce genre de bouses. Travailler dans le constructeur
est toujours assez délicat.

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
InnerClass() {
AbstractClassImpl zz = new AbstractClassImpl();
}

private class AbstractClassImpl extends AbstractClass {
int getLength() {
return TestNull.this.test.length();
}
}
}

private abstract class AbstractClass {
public AbstractClass() {
System.out.println("getLength()=" + getLength());
}

abstract int getLength();
}

public static void main(String[] args) {
TestNull testNull1 = new TestNull();
}
}
</code>

--
Nicolas Delsaux
"L'humour est une chose trop sérieuse pour être confiée aux rigolos."
Marcel Gotlib

Le 29.09 2003, Armel HERVE <armel.herve@netcourrier.com> s'est levé(e) et
s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

Si le code que tu utilises ressemble à ça, t'es vraiment dans la merde.

Parce que comme paquet de nouilles moche et avec des dépendances
croisées, on ne fait pas mieux.

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

On va essayer, avec une petit cinématique du code ...

Démarrage.
Appel au constructeur de TestNull, qui initialise la chaîne, puis appelle
le constructeur de InnerClass (déja, c'est super moche, mais bon...).
Le constructeur de InnerClass appelle à son tour (sans conserver de
références (super)) celui de AbstractClassImpl.
AbstractClassImpl dérivant de AbstractClass, le constructeur de cette
classe est appelé. Dans ce constructeur, on appelle la méthode abstraite
getLength.
Cette méthode est implémentée dans AbstractClassImpl (encore heureux !)
et retourne théoriquement la valeur de TestNull.test.length().
Or ici, on est toujours dans le constructeur de TestNull. Il n'est donc
pas possible d'utiliser le pointeur this dans cette méthode (puisque le
this n'existe pas encore réellement). Et donc, test n'existe pas, et
test.length renvoie une NullPointerException.
CQFD.
Mon conseil ? Evites ce genre de bouses. Travailler dans le constructeur
est toujours assez délicat.

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
InnerClass() {
AbstractClassImpl zz = new AbstractClassImpl();
}

private class AbstractClassImpl extends AbstractClass {
int getLength() {
return TestNull.this.test.length();
}
}
}

private abstract class AbstractClass {
public AbstractClass() {
System.out.println("getLength()=" + getLength());
}

abstract int getLength();
}

public static void main(String[] args) {
TestNull testNull1 = new TestNull();
}
}
</code>

--
Nicolas Delsaux
"L'humour est une chose trop sérieuse pour être confiée aux rigolos."
Marcel Gotlib

Vous avez filtré cet utilisateur ! Consultez son message

Le 29.09 2003, Armel HERVE s'est levé(e) et
s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

Si le code que tu utilises ressemble à ça, t'es vraiment dans la merde.

Parce que comme paquet de nouilles moche et avec des dépendances
croisées, on ne fait pas mieux.

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

On va essayer, avec une petit cinématique du code ...

Démarrage.
Appel au constructeur de TestNull, qui initialise la chaîne, puis appelle
le constructeur de InnerClass (déja, c'est super moche, mais bon...).
Le constructeur de InnerClass appelle à son tour (sans conserver de
références (super)) celui de AbstractClassImpl.
AbstractClassImpl dérivant de AbstractClass, le constructeur de cette
classe est appelé. Dans ce constructeur, on appelle la méthode abstraite
getLength.
Cette méthode est implémentée dans AbstractClassImpl (encore heureux !)
et retourne théoriquement la valeur de TestNull.test.length().
Or ici, on est toujours dans le constructeur de TestNull. Il n'est donc
pas possible d'utiliser le pointeur this dans cette méthode (puisque le
this n'existe pas encore réellement). Et donc, test n'existe pas, et
test.length renvoie une NullPointerException.
CQFD.
Mon conseil ? Evites ce genre de bouses. Travailler dans le constructeur
est toujours assez délicat.

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
InnerClass() {
AbstractClassImpl zz = new AbstractClassImpl();
}

private class AbstractClassImpl extends AbstractClass {
int getLength() {
return TestNull.this.test.length();
}
}
}

private abstract class AbstractClass {
public AbstractClass() {
System.out.println("getLength()=" + getLength());
}

abstract int getLength();
}

public static void main(String[] args) {
TestNull testNull1 = new TestNull();
}
}
</code>

--
Nicolas Delsaux
"L'humour est une chose trop sérieuse pour être confiée aux rigolos."
Marcel Gotlib

Armel HERVE

30/09/2003 à 08:33

In article ,
says...

Le 29.09 2003, Armel HERVE s'est levé(e) et
s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

Si le code que tu utilises ressemble à ça, t'es vraiment dans la merd e.

Parce que comme paquet de nouilles moche et avec des dépendances
croisées, on ne fait pas mieux.

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

On va essayer, avec une petit cinématique du code ...

Démarrage.
Appel au constructeur de TestNull, qui initialise la chaîne, puis appel le
le constructeur de InnerClass (déja, c'est super moche, mais bon...).
Le constructeur de InnerClass appelle à son tour (sans conserver de
références (super)) celui de AbstractClassImpl.
AbstractClassImpl dérivant de AbstractClass, le constructeur de cette
classe est appelé. Dans ce constructeur, on appelle la méthode abstra ite
getLength.
Cette méthode est implémentée dans AbstractClassImpl (encore heureu x !)
et retourne théoriquement la valeur de TestNull.test.length().
Or ici, on est toujours dans le constructeur de TestNull. Il n'est donc
pas possible d'utiliser le pointeur this dans cette méthode (puisque le
this n'existe pas encore réellement). Et donc, test n'existe pas, et
test.length renvoie une NullPointerException.
CQFD.
Mon conseil ? Evites ce genre de bouses. Travailler dans le constructeur
est toujours assez délicat.

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
Ceci est la réponse que SUN m'a fourni:

Hello

Thank you for reporting this issue.

This bug is being tracked under the following:

Bug Id: 4030374
Category: java
Subcategory: compiler
Synopsis: * Initialization of up-level links, immediately after
super(), occurs too late.

Here is the public summary from the bug report:

In previous releases of the compiler,
up-level references from a class's instance methods did not work until
after
the superclass constructor has returned. For example, the following
program
would fail at runtime:

class SuperInitBug {
static class S {
void hi() { System.out.println("You shouldn't see this
message"); }
S() { hi(); }
}
static class T {
void greet() { System.out.println("You won't see this
either."); }
class N extends S {
void hi() {
T.this.greet(); //throws a
NullPointerException!!
}
}
}
public static void main(String av[]) { new T().new N(); }
}

Fixing this bug required initializing the synthetic member
this$0 before calling the superclass constructor. Although
specifically allowed by the VM specification (4.8.2),
the verifier failed to allow it prior to 1.4. Therefore, this code
change only appears when you use the -target 1.4 compiler flag.
(end of public summary).

Please refer to the bug report for more information:
http://developer.java.sun.com/developer/bugParade/bugs/4030374.html

To gain the advantage of this fix, you will need to compile
your .java files with:
javac -target 1.4 [... other javac flags...] source.java

Hope this helps, and Best Regards-
Tim Bell J2SE Engineering
Sun Microsystems Java Software http://java.sun.com/j2se

In article <XnF94065363DBE94nicolasdelsauxonline@213.228.0.4>,
nicolas.delsaux@online.fr.invalid says...

Le 29.09 2003, Armel HERVE <armel.herve@netcourrier.com> s'est levé(e) et
s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

Si le code que tu utilises ressemble à ça, t'es vraiment dans la merd e.

Parce que comme paquet de nouilles moche et avec des dépendances
croisées, on ne fait pas mieux.

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

On va essayer, avec une petit cinématique du code ...

Démarrage.
Appel au constructeur de TestNull, qui initialise la chaîne, puis appel le
le constructeur de InnerClass (déja, c'est super moche, mais bon...).
Le constructeur de InnerClass appelle à son tour (sans conserver de
références (super)) celui de AbstractClassImpl.
AbstractClassImpl dérivant de AbstractClass, le constructeur de cette
classe est appelé. Dans ce constructeur, on appelle la méthode abstra ite
getLength.
Cette méthode est implémentée dans AbstractClassImpl (encore heureu x !)
et retourne théoriquement la valeur de TestNull.test.length().
Or ici, on est toujours dans le constructeur de TestNull. Il n'est donc
pas possible d'utiliser le pointeur this dans cette méthode (puisque le
this n'existe pas encore réellement). Et donc, test n'existe pas, et
test.length renvoie une NullPointerException.
CQFD.
Mon conseil ? Evites ce genre de bouses. Travailler dans le constructeur
est toujours assez délicat.

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
Ceci est la réponse que SUN m'a fourni:

Hello

Thank you for reporting this issue.

This bug is being tracked under the following:

Bug Id: 4030374
Category: java
Subcategory: compiler
Synopsis: * Initialization of up-level links, immediately after
super(), occurs too late.

Here is the public summary from the bug report:

In previous releases of the compiler,
up-level references from a class's instance methods did not work until
after
the superclass constructor has returned. For example, the following
program
would fail at runtime:

class SuperInitBug {
static class S {
void hi() { System.out.println("You shouldn't see this
message"); }
S() { hi(); }
}
static class T {
void greet() { System.out.println("You won't see this
either."); }
class N extends S {
void hi() {
T.this.greet(); //throws a
NullPointerException!!
}
}
}
public static void main(String av[]) { new T().new N(); }
}

Fixing this bug required initializing the synthetic member
this$0 before calling the superclass constructor. Although
specifically allowed by the VM specification (4.8.2),
the verifier failed to allow it prior to 1.4. Therefore, this code
change only appears when you use the -target 1.4 compiler flag.
(end of public summary).

Please refer to the bug report for more information:
http://developer.java.sun.com/developer/bugParade/bugs/4030374.html

To gain the advantage of this fix, you will need to compile
your .java files with:
javac -target 1.4 [... other javac flags...] source.java

Hope this helps, and Best Regards-
Tim Bell tim.bell@sun.com J2SE Engineering
Sun Microsystems Java Software http://java.sun.com/j2se

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
says...

Le 29.09 2003, Armel HERVE s'est levé(e) et
s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"

Bonjour à tous,
dans le code qui suit (qui est stupide, je sais, mais il a la même
structure qu'un programme sur lequel je suis),

Si le code que tu utilises ressemble à ça, t'es vraiment dans la merd e.

Parce que comme paquet de nouilles moche et avec des dépendances
croisées, on ne fait pas mieux.

est-ce que quelqu'un pourrait m'expliquer pourquoi TestNull.this n'est
pas accessible (et fait planter) dans AbstractClassImpl.getLength() ?

On va essayer, avec une petit cinématique du code ...

Démarrage.
Appel au constructeur de TestNull, qui initialise la chaîne, puis appel le
le constructeur de InnerClass (déja, c'est super moche, mais bon...).
Le constructeur de InnerClass appelle à son tour (sans conserver de
références (super)) celui de AbstractClassImpl.
AbstractClassImpl dérivant de AbstractClass, le constructeur de cette
classe est appelé. Dans ce constructeur, on appelle la méthode abstra ite
getLength.
Cette méthode est implémentée dans AbstractClassImpl (encore heureu x !)
et retourne théoriquement la valeur de TestNull.test.length().
Or ici, on est toujours dans le constructeur de TestNull. Il n'est donc
pas possible d'utiliser le pointeur this dans cette méthode (puisque le
this n'existe pas encore réellement). Et donc, test n'existe pas, et
test.length renvoie une NullPointerException.
CQFD.
Mon conseil ? Evites ce genre de bouses. Travailler dans le constructeur
est toujours assez délicat.

Merci pour vos lumières!!!

Armel

<code>
package com.test;
class TestNull {
private String test = null;

public TestNull() {
test = "Hello";

InnerClass aa = new InnerClass();
}

private class InnerClass {
Ceci est la réponse que SUN m'a fourni:

Hello

Thank you for reporting this issue.

This bug is being tracked under the following:

Bug Id: 4030374
Category: java
Subcategory: compiler
Synopsis: * Initialization of up-level links, immediately after
super(), occurs too late.

Here is the public summary from the bug report:

In previous releases of the compiler,
up-level references from a class's instance methods did not work until
after
the superclass constructor has returned. For example, the following
program
would fail at runtime:

class SuperInitBug {
static class S {
void hi() { System.out.println("You shouldn't see this
message"); }
S() { hi(); }
}
static class T {
void greet() { System.out.println("You won't see this
either."); }
class N extends S {
void hi() {
T.this.greet(); //throws a
NullPointerException!!
}
}
}
public static void main(String av[]) { new T().new N(); }
}

Fixing this bug required initializing the synthetic member
this$0 before calling the superclass constructor. Although
specifically allowed by the VM specification (4.8.2),
the verifier failed to allow it prior to 1.4. Therefore, this code
change only appears when you use the -target 1.4 compiler flag.
(end of public summary).

Please refer to the bug report for more information:
http://developer.java.sun.com/developer/bugParade/bugs/4030374.html

To gain the advantage of this fix, you will need to compile
your .java files with:
javac -target 1.4 [... other javac flags...] source.java

Hope this helps, and Best Regards-
Tim Bell J2SE Engineering
Sun Microsystems Java Software http://java.sun.com/j2se

Pourquoi ca plante ?

4 réponses

Veuillez sélectionner un problème