Quelqu'un pourrait-il expliquer le type d'octet Java?
Ceci ne compile pas: P> tandis que cela fait: P> Integer i = (byte)3;
3 Réponses :
Premier snippet produit une erreur de compilation en raison de toutes les constantes numériques par défaut sont int s en java.
Mais alors les deux premières lignes devraient échouer?
@Cse: C'est exactement ce que j'ai décrit dans cette réponse.
Oui, mais les lignes pour B1 et B2 compilent. B3 échoue.
Spécification de la langue Java 5.6.2 Promotion numérique binaire: "Sinon, les deux opérandes sont convertis type INT".
Java convertit les deux opérandes vers et int. Le résultat de l'addition est un int.
Ajout: La différence entre B3 et B4 est que, dans B4, c'est une expression constante (15.28), dans B3, c'est littéral.
JVM Spec, a tout ce dont vous avez besoin. Java.sun.com/docs/books/ JVMS / second_edition / HTML / ...
Qu'est-ce qui se passe avec les cours d'emballage? Il semble compter intuitif que l'INT peut s'intégrer dans un octet, mais un octet ne peut pas s'intégrer dans un entier
Essayant toujours de comprendre les emballages. Il est assez difficile de comprendre ce qui se passerait des spécifications.
Le comportement de l'emballage repose sur le fait que les littéraux entier sont traités spécifiquement par le compilateur (c'est-à-dire un littéral entier qui convient à la plage d'octets peut être utilisé comme octet). Si vous utilisez 128+ ou l'attribuez à une variable à l'avance, il s'arrête pour fonctionner. Et non, ne me demandez pas où cela est décrit dans les JLS :)
B6 fonctionne en raison du rétrécissement du temps de compilation des constantes littérales. B7 ne fonctionne pas car la rétrécissement du temps de compilation est limitée à toutes les primitives mais longue (type d'étrange, aucune idée de la raison)
La partie intéressante est §5.2 de la JLS : aucune idée de la raison > I ne fonctionne pas si - l'élargissement devrait fonctionner juste bien et, en fait, le compilateur devrait générer quelque chose comme Assez intéressant suffisamment à l'aide du compilateur Eclipse Java Trouver la bonne partie de la JLS était moins de travail que le formatage de celui-ci qu'il est quelque peu lisible - donc probablement plus facile si vous suivez le lien. integer.valueof ((octet) 3); de toute façon. L'utilisation de l'appel explicite fonctionne comme prévu, c'est-à-dire que l'élargissement se produit. Integer I = (octet) 3; Compile tout simplement bien, ce qui me conduit à croire que vous venez de trouver un bogue dans Javac - Félicitations! (Eh bien que cela soit ou un bogue dans le compilateur Eclipse; mais le comportement de Eclipse me semble correct). Fwiw J'ai signalé le bug contre Javac à Oracle.
Le je me suis également confondu ... Je suppose que cela serait traduit à quelque chose comme = nouveau entier ((octet) 3)); Mais cela fonctionnerait réellement ... je suppose que ce n'est pas vraiment clarifié dans les JLS
@Cse no, le compilateur utilise la méthode (comme n'importe qui à l'aide de l'API d'emballage, le constructeur ne devrait vraiment pas être public), mais oui, cela ressemble à un bogue pour moi parce que l'appel explicite en fait travaux. Voici The BugReport, toujours non révisé par Oracle, en ce qui concerne l'écriture - prendra probablement quelques jours.
Sans les messages d'erreur et les numéros de ligne des plaintes, cela est plutôt difficile à répondre.
En outre,
octet x = 126 + 1; fonctionne mais pasoctet y = 126 + 2; en quelque sorte, lorsque vous utilisez une valeur calculable, le compilateur vérifie si le conteneur est suffisamment large. . Je ne trouve pas la référence dans les JLS, cependant.Ceci est longuement discuté dans les réponses à cette question: lien
JLS 5.2: Conversion d'affectation
octet b7 = (long) 127; ne compile pas, même si 127 peut s'intégrer dans un octetOui, car JLS 5.2 dit qu'une conversation de rétrécissement n'est effectuée que pour l'octet, court, char et int. Long est spécial à cet égard.
Je demande une certaine assemblée demain à ce sujet. J'abandonne jusqu'à présent, j'ai essayé des choses, mais l'octet en integer boxing est bizarre ...