Guillaume Desnoix wrote:
Je me corrige: tout le monde a raison ;-)Sinon, la JSR 202 devrait r�soudre le probl�me des diff�rents bytes-codes g�n�r�s, en effet,
J'avais fait mes tests sur Integer.class et non Integer[].class. La difference entre jikes et javac/jbc porte sur les tableaux.
La classe des composants du tableau n'est pas initialisee avec jikes, ce qui est logique et correct, comme l'a dit Remi. Bogue javac/jbc.
Mais vu le bytecode genere, je commence a me dire que la construction .class n'est franchement pas terrible. Malgre l'allocation, new X[0].getClass() me semble plus 'propre' (new X[0] pourrait etre une constante publique). Avec un tel code, le bytecode est identique avec les 3 compilos, le comportement est correct, c'est plus sur et ca me semble meme plus performant (si constante). Y'a du reusinage dans l'air.
Guillaume
la JSR propose de rajouter la possibilit� de charger une classe par une instruction sp�cifique du byte-code :*
* Adding support for class literals.
Since JDK 1.1 the Java^TM language has included support for accessing class literals though
expressions such as "MyClassName.class". However there has been no direct support for this
in the class file format and it appears that adding class file support will allow significantly more
efficient access to class literals.
Remi
