Discussion :

[xxaragornxx]

Bonjour,

Dans le cadre d'un portage de java 1.4 vers 1.5, je suis confronté au pb suivant:

le code: (Toto étant une classe et ici init() une de ses méthodes)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public void init() {
     String name = Toto.class.getName();
 
[...]
 
}

retourne l'erreur suivante:

Exception in thread "main" java.lang.VerifyError: ( class: com/blabla/Toto, method: init signature ()V) Illegal type in constant pool

QQun a une idée du pourquoi du comment ?
Merci !

[Satch]

ça m'étonnerait que ça vienne du bout de code que tu as mis ici.

Essaye d'y aller en debug, pour voir a quel moment l'erreur est balancée.

[xxaragornxx]

ça m'étonnerait que ça vienne du bout de code que tu as mis ici.

Essaye d'y aller en debug, pour voir a quel moment l'erreur est balancée.

Non, non, je confirme, cela vient bien de ce bout de code !
En effet, ce principe est appliqué plusieurs fois dans l'appli et notamment dans dans des System.out.println: (exemple ici)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.out.println("La classe utilisée est: " + Toto.class.getName());

Or commenter ce code permet de ne plus avoir l'erreur (que l'on rencontre plus tard dans d'autres classes et dans des cas plus importants qu'un sysout)

J'ai lu que maintenant avec la 5.0 on récupèrerait le "binary name" (qui reste une String)...
C'est-à-dire ?
Et pourquoi cela ferait planter le chargement d'une classe ne contenant que des System.out.println ?

[Satch]

Visiblement c'est un problème au chargement de la classe.

Extrait de la doc : "Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem."

Tu peux nous copier le StackTrace ?

[xxaragornxx]

Visiblement c'est un problème au chargement de la classe.

Extrait de la doc : "Thrown when the "verifier" detects that a class file, though well formed, contains some sort of internal inconsistency or security problem."

Tu peux nous copier le StackTrace ?

Oui, c'est ce que j'ai lu.
Au niveau de la Stacktrace je n'en ai pas plus que ce que j'ai listé là haut...
J'ai lancé l'appli avec l'option verbose:class pour voir le chargement des classes et effectivement le class-loader ne parvient pas à la charger et génère cette même erreur... (sans plus d'information)

[Satch]

C'est hallucinant le peu d'info qu'on trouve sur le net à ce sujet...

Ce que j'ai pu glaner par ci par là :
- un gars avait le même pb, avec un code tout simple. Il faisait ça sous linux, et pourtant sous windows ça marchait.
- un autre avait aussi le même pb, il a désinstallé la VM de microsoft et réinstallé celle de Sun, ça a marché après.

Pour info, voici le code qui faisait la même erreur chez le premier (il marche parfaitement chez moi) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
import javax.swing.*; 
 
public class Projet extends JFrame 
{ 
   JTextField zone_1; 
 
   public static void main(String[] args) 
   { 
      Projet projet = new Projet(); 
 
      projet.setSize(640,480); 
      projet.show(); 
   } 
 
   Projet() 
   { 
      super("Blabla"); 
 
      zone_1 = new JTextField(10); 
      getContentPane().add(zone_1); 
 
      zone_1.setText("Hello"); 
   } 
}

ça serait interressant que tu essayes de compiler et d'executer ce code, juste pour voir s'il marche chez toi.

En tout cas je me sens tout désarmé, c'est la première fois que j'entends un truc pareil et je suis vraiment curieux de savoir d'où ça vient...

[XristofGreek]

Tu pourrais pas essayer de renommer ta fonction init() de la classe Toto en myInit() par exemple, s'il te plait ? Il me semble que j'ai déjà rencontré ça quelque part.
Je me demande si c'est pas devenu un mot réservé avec la version java 1.5

[Satch]

Une chose est sure, c'est pas un mot réservé (Applet a une méthode init(), entre autre)

[XristofGreek]

non effectivement "réservé" n'est pas le bon terme... Mais j'ai une intuition la dessus, et si xxaragornxx pouvait essayer, ça pourrait peut-être permettre de trouver une piste pour expliquer le phénomène.

[xxaragornxx]

Merci de votre participation !

Le mot init n'est pas en cause pour avoir essayé avec d'autres noms de méthodes.

Sinon je suis allé voir là:
http://java.sun.com/j2se/1.5.0/compatibility.html

Virtual Machine - Previously, evaluating a class literal (for example, Foo.class) caused the class to be initialized; as of 5.0, it does not. Code that depends on the previous behavior should be rewritten.

You can use the following code to force initialization of a class:

//... Foo.class ... //OLD CODE
... forceInit(Foo.class) ... //NEW CODE

/**
* Forces the initialization of the class pertaining to the specified
* <tt>Class</tt> object. This method does nothing if the class is already
* initialized prior to invocation.
*
* @param klass the class for which to force initialization
* @return <tt>klass</tt>
*/
public static <T> Class<T> forceInit(Class<T> klass) {
try {
Class.forName(klass.getName(), true, klass.getClassLoader());
} catch (ClassNotFoundException e) {
throw new AssertionError(e); // Can't happen
}
return klass;
}
The new behavior is a consequence of the fact that the VM now supports class literals in the constant pool. The old behavior remains in classes compiled with a pre-5.0 compiler or with the -target 1.4 flag, even if run in the 5.0 VM.

For more information, see Initialization of Classes and Interfaces (section 12.4) in The Java Language Specification. Note that the language specification hasn't changed; it never listed class literal evaluation as an initialization trigger.

Ca ne change rien chez moi. Toutefois je n'ai pas encore testé de compiler en 1.4 pour faire tourner sur une JVM 1.5 (bcp de dépendances à metter à jour et en même temps cette solution ne me paraît pas satisfaisante)

Enfin, Satch je n'ai pas encore essayé ton bout de code pour le tester. Je vais faire l'essai. Histoire de voir si c'est lié...