Définition de la valeur courte Java

114

J'écris un petit code en J2ME. J'ai une classe avec une méthode setTableId(Short tableId). Maintenant, quand j'essaie d'écrire, setTableId(100)cela donne une erreur de compilation. Comment puis-je définir la valeur courte sans déclarer une autre variable courte?

Lors de la définition de la Longvaleur, je peux utiliser setLongValue(100L)et cela fonctionne. Alors, que Lsignifie ici et quel est le caractère de Shortvaleur?

Merci

java literals primitive-types Mubashar
la source

Lest juste un suffixe utilisé pour indiquer un longlittéral.

missingfaktor

174

En Java, les littéraux entiers sont de type int par défaut. Pour d'autres types, vous pouvez le suffixe littéral avec une lettre insensible à la casse comme L, D, Fspécifier une longue, double ou flottant, respectivement. Notez qu'il est courant d'utiliser des lettres majuscules pour une meilleure lisibilité.

La spécification du langage Java ne fournit pas le même sucre syntaxique pour les types octets ou courts. Au lieu de cela, vous pouvez le déclarer comme tel en utilisant un casting explicite:

byte foo = (byte)0;
short bar = (short)0;

Dans votre setLongValue(100L)appel de méthode, vous n'avez pas nécessairement besoin d'inclure le Lsuffixe car dans ce cas, le littéral int est automatiquement élargi à un long. C'est ce qu'on appelle l'élargissement de la conversion primitive dans la spécification du langage Java.

Lauri
la source

16

Il existe également des suffixes pour d'autres types: d/ Dfait un doubleet f/ Ffait un float!

Joachim Sauer

6

Aussi: les littéraux qui correspondent à la taille n'ont pas besoin d'être castés: vos deux exemples fonctionnent également sans le casting.

Joachim Sauer

Vous avez raison sur les deux. J'aurais dû être plus clair que je parle ici de littéraux entiers, pas de littéraux à virgule flottante.

Lauri

4

@Joachim: Aucune distribution requise uniquement pour J5 +; J2ME est malheureusement toujours à J4 (un J4 sérieusement dépouillé).

Lawrence Dol

2

@JoachimSauer, que signifie "rentrer dans la taille"? Je demande parce que je devais spécifiquement jeter 0comme (short)0pour contourner une possible lossy conversion from int to shorterreur, même si 0 est un court.

ryvantage

34

Il n'y a pas d'octet ou de littéral court. Vous devez diffuser en bref en utilisant(short)100

er4z0r
la source

9

En général, vous pouvez simplement convertir la variable en un fichier short.

Vous pouvez également rencontrer des problèmes comme celui-ci qui peuvent prêter à confusion. C'est parce que l' +opérateur les promeut à unint

Diffuser les éléments n'aidera pas:

Vous devez lancer l'expression:

brûlures mates
la source

1

N'oubliez pas qu'il y a une raison pour laquelle short + short = int. Si la somme de deux courts-circuits est supérieure à la valeur courte maximale de la machine, la conversion en short produira des résultats inattendus ou lèvera une exception, si elle est prise en charge par languaje.

DGoiko

2

Avec cette logique, ajouter deux entiers reviendrait un long;)

mat brûle le

1

Et je cherche cela si mes sommes peuvent dépasser Integer.MAX_VALUE. Je ne défends pas la décision de renvoyer int (ce qui est probablement lié à la façon dont le HW effectue réellement les sommes), je dis simplement que les gens devraient confirmer que le résultat remplit réellement un court avant de le mettre là. J'ai rencontré plus de bogues limitant la capacité courte que le plafonnement int ainsi, probablement en raison de la taille des nombres impliqués. 2 petits octets de réservoirs java pour un plafond court très rapidement

DGoiko le

1

J'ai relu mon commentaire et je n'ai pas précisé mon argument. La première phrase est déroutante et je n'aurais pas dû le dire et juste laisser le reste, il semble qu'il y ait deux déclarations liées.La raison derrière le fait que short + short est int peut être lue ici: docs.oracle.com/javase/specs/ jvms / se8 / html /… , il n'y a pas d'opérations de somme pour faire court dans JVM. L'intérieur de Java est de 32 bits, et lorsque ces décisions ont été prises, la plupart des ordinateurs étaient de 32 bits, donc int ressemblait à la meilleure idée, je suppose.

DGoiko le

1

Notez également que, comme expliqué ici stackoverflow.com/a/27123302/9465588 , JVM a effectivement servi au moins 32 bits de son espace de mémoire virtuelle par champ de classe, donc déclarer des champs courts ne permet pas du tout d'économiser de la mémoire. Je ne sais pas si Java a changé cela. J'ai tendance à ne jamais utiliser de valeurs courtes à moins qu'il n'y ait une restriction externe impliquée, comme dans un DAO

DGoiko le

8

Vous pouvez utiliser setTableId((short)100). Je pense que cela a été modifié dans Java 5 afin que les littéraux numériques attribués à byte ou short et à portée de la cible soient automatiquement supposés être le type de cible. Ces dernières JVM J2ME sont cependant dérivées de Java 4.

Lawrence Dol
la source

PS: Bienvenue dans la douleur du moyen-âge du codage pour J2ME. J'ai hâte que les appareils portables rattrapent les ordinateurs de bureau de l'an 2000.

Lawrence Dol

3

Il n'y a pas de "J4" (et pas de "J5". Veuillez ne pas rendre le schéma de version / dénomination Java plus déroutant qu'il ne l'est déjà.

Joachim Sauer

2

@Joachim: Java 1, Java 2, Java 5, Java 6 et Java 7 sont bien connus et sont ainsi désignés; il n'est pas trop difficile d'extrapoler ce que signifieraient Java 3 et Java 4. «Jn» est simplement une abréviation de l'évidence. L'adoption de la nomenclature actuelle (et espérons-le définitive) de Sun pour toutes les versions réduit la confusion.

Lawrence Dol

2

@Joachim: Selon le dernier mot de Sun sur le sujet, le premier "1" de Java "1.x" doit être traité comme s'il n'était jamais là quand on se réfère aux versions en discussion, et est conservé dans la version émise par les JVM uniquement pour des raisons de compatibilité. Ainsi, Java 2 est cette version qui était auparavant connue sous le nom de 1.2, d'où J2SE est originaire (vous noterez que dans le même temps, Sun recommandait de ne plus utiliser J2xE, mais plutôt JavaEE, JavaSE et JavaME). Il s'ensuit que 1.3 est Java 3, 1.4 est Java 4, 1.5 est Java 5, 1.6 est Java 6 et 1.7 est Java 7. Sérieusement, ce n'est pas si difficile à raisonner.

Lawrence Dol

2

Le "1" n'a été supprimé que dans Java 5 et versions ultérieures. Java 1.0-1.4 est toujours désigné par ce nom par Sun. Et cela est fait intentionnellement, car Sun a utilisé «Java 2» pour désigner Java 1.2 jusqu'à Java 1.5 / Java 5. C'est très déroutant, mais inventer de nouveaux noms que Sun n'a jamais utilisés ne facilite pas les choses.

Joachim Sauer

Définition de la valeur courte Java

Réponses: