Existe-t-il des utilisations réelles du type primitif octet Java?

Question

Pour des raisons inexplicables l' byte type primitif est signé en Java. Cela signifie que les valeurs valides vont de -128..127 au lieu de l'habituel 0..255 gamme qui représente 8 bits significatifs dans un octet (sans bit de signe).

Cela signifie que tous les octets de code de manipulation n'est généralement des calculs avec des entiers et finissent par masquer les 8 derniers bits.

Je me demandais si il n'y a aucun scénario de la vie réelle où le Java byte type primitif s'adapte parfaitement ou si c'est simplement un complètement inutile décision de conception?

---

EDIT: Le seul réel de cas d'utilisation a été codés sur un seul octet d'espace réservé pour le code natif. En d'autres termes, de ne pas être manipulé comme un octet à l'intérieur du code Java.

Answer 1

Josh Bloch récemment mentionné dans une présentation que c'est l'une des erreurs commises dans la langue.

Je pense que la raison derrière cela est que java n'a pas non signé types numériques, et byte devraient se conformer à cette règle. (Remarque: char n'est pas signée, mais ne permet pas de représenter des nombres)

Comme pour la question: je ne peux pas penser à un exemple. Et même si il y avait des exemples, ils seraient moins nombreux que ceux qui pour 0..255, et ils pourraient être mises en œuvre à l'aide de masquage (plutôt que de la majorité)

Answer 2

byte, short, char types sont la plupart du temps inutile, sauf lorsqu'il est utilisé dans des tableaux pour économiser de l'espace.

Ni Java ou JVM a aucun soutien réel pour eux. Presque toutes les opérations sur ces promouvoir int ou long première. Nous ne pouvons même pas écrire quelque chose comme

    short a=1, b=2;
    a = a + b;  // illegal
    a = a << 1; // illegal

Alors pourquoi diable même pas la peine avec la définition d'opérations sur byte, short, char types? Tout ce qu'ils font faufiler dans l'élargissement des conversions qui vont surprendre le programmeur.

Answer 3

Étonnamment, j'ai simplement utilisé byte en Java pour la première fois la semaine dernière, j'ai donc un (quoique rare) de cas d'utilisation. J'ai écrit un Java natif de la fonction, ce qui vous permet d'implémenter une fonction dans une bibliothèque qui peut être appelée par Java. Types Java doivent être convertis à des types dans la langue maternelle, dans ce cas, C

La fonction nécessaire de prendre un tableau d'octets, mais (en oubliant l' byte type entièrement à l'époque) que j'ai eu il prendre un char[]. La signature de Java génère pour la fonction C donne le type de ce paramètre jcharArray, qui peut être transformée en un tas de jchars, qui sont typedef-ed en jni.h de unsigned short. Naturellement, ce n'est pas la même taille, c'est de 2 octets au lieu de 1. Cela a causé toutes sortes de problèmes avec le code sous-jacent. Faire la Java de type byte[] a entraîné une jbyteArray, et jbyte sur Linux est typedef-ed signed char, ce qui est la bonne taille

Answer 4

Son numérisée (ou tout autre signal) avec 8 bits signé des échantillons semble être la seule raisonnable exemple pour moi. Bien sûr, d'avoir signé octets est pas nécessaire de traiter de tels signaux et il peut être soutenu que Java "s'adapte parfaitement".

Personnellement, je ne crois pas l'avoir non signé est une erreur. Non seulement parce qu'il y a plus d'utilisation pour les octets non signés/ints, mais parce que je préfère une plus forte type de système. Il serait agréable d'être en mesure de préciser que les nombres négatifs ne sont pas valables et permettent compilateur vérifie et des exceptions d'exécution pour les violations.

Answer 5

byte a une large utilisation dans le développement applet Java Card. Parce que les cartes ont des ressources limitées, tous les bits de la mémoire est précieuse. Par la façon dont les processeurs de carte ont des limites dans le traitement de valeurs entières. int type de soutien est facultatif et java.lang.String n'est pas pris en charge pour tous les entiers de fonctionnement et de stockage des données se fait par byte et short les variables et les tableaux. Comme les littéraux entiers sont d' int type, ils devraient être explicitement exprimées byte ou short dans l'ensemble du code. La Communication avec la carte passe par des commandes APDU qui est remis à l'applet comme un tableau d' bytes qui devraient être décomposé en bytes pour décoder classe de commande, les instructions et les paramètres. En regardant le code suivant, vous voyez combien byte et short types sont importants pour Java Card développement:

package somepackage.SomeApplet;

import javacard.framework.*;
import org.globalplatform.GPSystem;
import org.globalplatform.SecureChannel;

public class SomeApplet extends Applet {

    // Card status
    private final static byte ST_UNINITIALIZED     = (byte) 0x01;
    private final static byte ST_INITIALIZED       = (byte) 0x02;

    // Instructions & Classes
    private final static byte PROP_CLASS           = (byte) 0x80;     

    private final static byte INS_INIT_UPDATE      = (byte) 0x50;
    private final static byte INS_EXT_AUTH         = (byte) 0x82;

    private final static byte INS_PUT_DATA         = (byte) 0xDA;
    private final static byte INS_GET_RESPONSE     = (byte) 0xC0;
    private final static byte INS_GET_DATA         = (byte) 0xCA;


    private final static short SW_CARD_NOT_INITIALIZED       = (short) 0x9101;  
    private final static short SW_CARD_ALREADY_INITIALIZED   = (short) 0x9102;  

    private final static byte OFFSET_SENT = 0x00;
    private final static byte OFFSET_RECV = 0x01;
    private static short[] offset;

    private static byte[] fileBuffer;
    private static short fileSize = 0;

    public static void install(byte[] bArray, short bOffset, byte bLength) {
        new SomeApplet( bArray, bOffset, bLength);
    }

    public RECSApplet(byte[] bArray, short bOffset, byte bLength) {
        offset = JCSystem.makeTransientShortArray((short) 2, JCSystem.CLEAR_ON_RESET);
        fileBuffer = new byte[FILE_SIZE];

        byte aidLen = bArray[bOffset];
        if (aidLen== (byte)0){
            register();
        } else {
            register(bArray, (short)(bOffset+1), aidLen);
        }
    }

    public void process(APDU apdu) {
        if (selectingApplet()) {
            return;
        }
        byte[] buffer = apdu.getBuffer();
        short len = apdu.setIncomingAndReceive(); 

        byte cla = buffer[ISO7816.OFFSET_CLA];
        byte ins = buffer[ISO7816.OFFSET_INS];
        short lc = (short) (buffer[ISO7816.OFFSET_LC] & 0x00ff); 

        while (len < lc) {
            len += apdu.receiveBytes(len);
        }

        SecureChannel sc = GPSystem.getSecureChannel();
        if ((short)(cla & (short)0x80) == ISO7816.CLA_ISO7816) {
            switch (ins) {
                case INS_PUT_DATA:
                    putData(buffer, ISO7816.OFFSET_CDATA, offset[OFFSET_RECV], len);

                    if ((cla & 0x10) != 0x00) {
                        offset[OFFSET_RECV] += len;
                    } else {
                        fileSize = (short) (offset[OFFSET_RECV] + len);
                        offset[OFFSET_RECV] = 0;
                    }
                    return;

                case INS_GET_DATA:
                case INS_GET_RESPONSE:
                    sendData(apdu);
                    return;
                default:
                    ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
            }

        }
        else if ((byte) (cla & PROP_CLASS) == PROP_CLASS) {
            switch (ins) {
                case INS_INIT_UPDATE:
                case INS_EXT_AUTH:
                    apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, sc.processSecurity(apdu));
                    return;
                default:
                    ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
            }
        } else
            ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
    }

    // Some code omitted

}