primitivos - tipos de variables en java ejemplos

¿Hay algún uso de la vida real para el tipo primitivo de bytes de Java?

Question

Por algún motivo inexplicable, el tipo de primitiva de byte está firmado en Java. Esto significa que los valores válidos son -128..127 en lugar del rango habitual 0..255 que representa 8 bits significativos en un byte (sin un bit de signo).

Esto significa que todo el código de manipulación de bytes generalmente hace cálculos enteros y termina enmascarando los últimos 8 bits.

Me preguntaba si hay algún escenario de la vida real donde el tipo de primitivo Java byte encaja perfectamente o si es simplemente una decisión de diseño completamente inútil.

EDITAR: El único caso de uso real era un marcador de posición de un solo byte para el código nativo. En otras palabras, no debe manipularse como un byte dentro del código Java.

EDITAR: Ahora he visto un lugar donde un circuito cerrado interior necesitaba dividirse por 7 (números 0..32), por lo que se podría hacer una tabla de búsqueda con bytes como el tipo de datos para que el uso de la memoria se mantenga bajo pensando en el uso del caché L1 . Esto no se refiere a la firma / no firma pero fue un caso de uso real.

Answer 1

Creo que está firmado para ser coherente con short e int.

En cuanto a si se usa mucho, hace que la noción de "matrices de bytes" sea una construcción en lugar de una primitiva.

Eso es todo lo que tengo. :)

Answer 2

El sonido digitalizado (o cualquier otra señal) con muestras firmadas de 8 bits me parece el único ejemplo razonable. Por supuesto, tener bytes firmados no es un requisito para manejar tales señales y se puede argumentar si el byte de Java "encaja perfectamente".

Personalmente, creo que no haber firmado no es un error. No solo porque hay más uso para bytes / ints sin firmar, sino porque prefiero un sistema de tipo más fuerte. Sería bueno poder especificar que los números negativos no son válidos y permitir las verificaciones del compilador y las excepciones de tiempo de ejecución para las infracciones.

Answer 3

El tamaño del byte es de 8 bits. El tamaño del byte ayuda a procesar las entradas y salidas mientras se realizan funciones como escribir en un archivo o leer desde un archivo. Considere un escenario en el que quiera leer una entrada desde el teclado o desde cualquier archivo. Si usa la estructura de datos "byte", sabrá que está recibiendo un carácter a la vez, ya que el tamaño es de 8 bits. Por lo tanto, cada vez que recibe un flujo de entrada, sabe que en realidad está recibiendo un carácter a la vez.

Answer 4

En una máquina con palabras de más de 8 bits es algo útil si desea almacenar una gran cantidad de valores que se ajustan en un rango de 8 bits en una única matriz, pero por lo general no es una buena idea usarlos de otra manera ya que un byte es en realidad más esfuerzo para salir de la memoria que un int.

Sin embargo, recuerde que Java fue diseñado para dispositivos de consumo muy pequeños (decodificadores de TV). Supongo que si se hubiera utilizado de esta manera en microprocesadores pequeños de 8 bits, hubiera sido más útil, ya que se ajustaría exactamente al tamaño de la palabra y podría usarse para operaciones generales de "matemáticas" en una escala muy pequeña.

La única razón por la que puedo ver para que se firme es que un byte sin signo que interactúa con un int puede ser un poco confuso, ¡pero no estoy seguro de que sea más confuso que uno firmado!

Answer 5

Estoy usando bytes ahora en Java para un proyecto de Android bluetooth.

Answer 6

Josh Bloch recientemente mencionó en una presentación que este es uno de los errores en el lenguaje.

Creo que la razón detrás de esto es que java no tiene tipos numéricos sin signo, y el byte debe ajustarse a esa regla. (Nota: char no tiene firma, pero no representa números)

En cuanto a la pregunta en particular: no puedo pensar en ningún ejemplo. E incluso si hubiera ejemplos, serían menos que los de 0..255, y podrían implementarse usando enmascaramiento (en lugar de la mayoría)

Answer 7

Lo usé con frecuencia cuando estaba programando software y juegos para J2ME. En la mayoría de los dispositivos J2ME, tiene recursos limitados, por lo que almacenar, por ejemplo, el mapa de un nivel en una matriz de bytes consume menos recursos que almacenarlo en una matriz int.

Answer 8

Sorprendentemente, acabo de usar byte en Java por primera vez la semana pasada, así que tengo un caso de uso (aunque inusual). Estaba escribiendo una función Java nativa , que le permite implementar una función en una biblioteca a la que Java puede llamar. Los tipos de Java deben convertirse a tipos en el idioma nativo, en este caso C

La función necesitaba tomar una matriz de bytes, pero (olvidando el tipo de byte completo en ese momento) hice que tomara un char[] . La firma que Java genera para la función C da el tipo de ese parámetro como jcharArray , que se puede convertir a un grupo de jchar , que se jni.h en jni.h en unsigned short . Naturalmente, ese no es el mismo tamaño: son 2 bytes en lugar de 1. Esto causó todo tipo de problemas con el código subyacente. Hacer que el byte[] tipo Java byte[] resultara en un jbyteArray , y jbyte en Linux es typedef-ed en un signed char , que es el tamaño correcto

Answer 9

byte, short, char tipos de caracteres byte, short, char son en su mayoría inútiles, excepto cuando se usan en matrices para ahorrar espacio.

Ni Java ni JVM tienen ningún soporte real para ellos. Casi todas las operaciones en ellos los promocionarán a int o long primero. Ni siquiera podemos escribir algo como

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

Entonces, ¿por qué diablos se molestan en definir operaciones en byte, short, char types?

Todo lo que hacen es escabullirse en conversiones cada vez mayores que sorprenderán al programador.

Answer 10

byte tiene un uso extensivo en el desarrollo de applets para Java Card. Debido a que las tarjetas tienen recursos limitados, cada bit de memoria es precioso. Por cierto, los procesadores de tarjetas tienen limitaciones en el procesamiento de valores enteros. int soporte de tipo int es opcional y no se admite java.lang.String por lo que toda la operación de enteros y el almacenamiento de datos se realiza mediante byte y variables y matrices short . Dado que los literales enteros son del tipo int , se deben convertir explícitamente a byte o short en todo el código. La comunicación con la tarjeta pasa por los comandos APDU que se entregan al applet como un conjunto de byte que deben descomponerse en byte para decodificar la clase de comando, la instrucción y los parámetros. Si observa el siguiente código, verá cuántos byte y tipos short son importantes para el desarrollo de la tarjeta Java:

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

}