Je me demandais quelle est la taille maximale d'une classe Java. Comme indiqué ici, ici http: // docs. oracle.com/javase/specs/jvms/se5.0/html/classfile.doc.html#1546 Dans la structure d'attribut de code, la longueur du code est spécifiée sous forme de 4 octets, il s'agit donc d'un grand nombre. Ce que je n'ai pas compris, c'est que les attributs PC d'exception sont 2 octets. Comment fonctionner peut-il si la longueur du code est supérieure à 2 octets, mais des tables d'exception ne peuvent aborder que les 2 octets? P>
3 Réponses :
La table d'exception Index dans le code d'une méthode spécifique, dont le code ne peut en effet pas être supérieur à 64k. Mais comme il peut y avoir de nombreuses méthodes dans une classe, cette place en soi aucune restriction de la taille d'une classe. P>
mais l'attribut de code appartient déjà à la méthode, cela signifie que la longueur de code de la méthode peut être spécifiée comme 4 octets supérieure à 64k
Non, ça ne peut pas, voir la réponse de Joachims. Il existe également d'autres entités de taille courtes que l'adresse compense dans une méthode.
§ 4.8.1 Contraintes statiques de la spécification JVM dit: p>
La valeur de l'élément
code_length code> doit être inférieur à
65536 code>. p> blockQuote>
Donc, bien que ce soit une valeur de 4 octets, il ne doit pas dépasser 64k. p>
Je sais comment faire une expression dont la signature de type est plus longue que celle-ci-> codegolf.stackexchange.com/a/71829/39022 < / a>
Alors, je suis tombé sur ceci et je me suis ennuyé, alors j'ai décidé de l'essayer. (Exécutant Java 1.6.0_26 sur un Quad-Xeon MacPro 1,1)
s'avère, il y a une limite reconnue par Eclipse au moins, en disant qu'il ne peut y avoir plus de 65 535 octets dans une méthode. Cependant, pour une raison quelconque, cela ne s'applique qu'à la méthode principale et aux méthodes constructrices, pas à des méthodes de classe normales. Une fois que les méthodes principales et constructrices avaient moins de 65k, le code a fonctionné sans problèmes. Eclipse a eu quelques problèmes à faire face à de telles méthodes (100% de CPU pendant quelques secondes et d'icônes d'erreur Les Ghosts restent sur l'éditeur), mais le code a effectivement couru juste. P>
J'ai ajouté 5 méthodes supplémentaires Tous avaient au moins 100 km de code (principalement gibberish system.out.println ("bla")) et les méthodes elles-mêmes utilisaient quelques paramètres et ont renvoyé une valeur. Donc, ils étaient comme «normaux» comme je pouvais les faire. J'ai essayé de courir ces quelques fois, et ils couraient toujours parfaitement. P>
Donc, il semble qu'il y ait une limite de 65k, mais il ne s'agit certainement de la taille de la classe absolue et ne s'applique apparemment qu'à "spécial "Méthodes telles que les méthodes principales ou constructrices. P>
Cependant, dans mon cas au moins, le plus gros problème était que Eclipse ne pouvait tout simplement pas gérer ces types de fichiers. La CPU commence à aller à 100% et l'IDE entier semblait geler parfois. La plupart du temps, cela ressemblait à Eclipse recalculant simplement la mise en évidence de la syntaxe (!). Le reste du système était réactif pendant ce temps au moins, ce que je suppose en dit plus sur OS X que sur Java. P>
Bien sûr, pourquoi voudriez-vous jamais devenir proche de ces limites me dépasse. La raison et le bon sens, sinon les principes OO, auraient dû prendre en charge cela bien avant de se rapprocher de 65k. Mais c'était une bonne expérience, et hé, j'ai appris quelque chose! P>
Juste pour référence, c'est ce que j'ai testé sur: p>
Faire une énorme structure autogénéité dans le forge Minecraft déclenchera l'avertissement de 64k. Devait diviser les instructions qui décident comment la structure est intégrée à des méthodes séparées.