blocks|key|1970389|text|我认为它是为了与short和int保持一致而签名的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1970390|至于它是否被广泛使用，它使“字节数组”的概念成为一种构造而不是原语。|1970391|这真的是我的全部。:)|1970392|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I think it is signed in order to be consistent with short and int.

As to whether it is used much, it makes the notion of "byte arrays" a construct rather than a primitive.

That's really all I have. :)

blocks|key|1970455|text|Josh+Bloch最近mentioned+in+a+presentation说这是语言中的错误之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1970456|我认为这背后的原因是byte没有无符号的数字类型，java应该遵守这一规则。(注意：char是无符号的，但不代表数字)|style|CODE|1970457|至于这个特殊的问题:我想不出任何例子。即使有示例，它们也会比0..255的示例更少，并且它们可以使用掩码(而不是大多数)来实现。|1970458|entityMap|0|LINK|mutability|MUTABLE|url|http://www.youtube.com/watch?v=hcY8cYfAEwU^0|C|R|0|0|A|4|16|4|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@$A|W|B|X|F|G]|$A|Y|B|Z|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Josh Bloch recently <a href="http://www.youtube.com/watch?v=hcY8cYfAEwU" rel="noreferrer">mentioned in a presentation</a> that this is one of the mistakes in the language.

I think the reason behind this is that java does not have unsigned numeric types, and <code>byte</code> should conform to that rule. (Note: <code>char</code> is unsigned, but does not represent numbers)

As for the particular question: I can't think of any example. And even if there were examples, they would be fewer than the ones for 0..255, and they could be implemented using masking (rather than the majority)

blocks|key|1970631|text|数字化的声音(或任何其他信号)与8位有符号的样本似乎是我唯一合理的例子。当然，有符号字节并不是处理这类信号的必要条件，Java字节是否“完美”也是可以争论的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1970632|就我个人而言，我认为没有签名是一个错误。这不仅仅是因为unsigned+bytes/int有更多的用法，还因为我更喜欢更强的类型系统。如果能够指定负数是无效的，并允许编译器检查和运行时异常来检查违规情况，那就太好了。|1970633|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Digitized sound (or any other signal) with 8 bit signed samples seems like the only reasonable example to me. Of course having signed bytes is no requirement to handling such signals and it can be argued whether Java byte "fits perfectly".

Personally I think not having unsigned is a mistake. Not only because there's more use for unsigned bytes/ints but because I prefer a stronger type system. It would be nice to be able to specify that negative numbers are not valid and allow compiler checks and runtime exceptions for violations.

blocks|key|1970702|text|令人惊讶的是，我上周才第一次在Java语言中使用byte，所以我确实有一个用例(尽管不同寻常)。我正在写一个native+Java+function，它允许你在一个库中实现一个可以被Java调用的函数。Java类型需要转换为本机语言中的类型，在本例中为C|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1970703|该函数需要接受一个字节数组，但是(当时完全忘记了byte类型)我让它接受一个char[]。Java为C函数生成的签名将该参数的类型指定为jcharArray，可以将其转换为一堆jchar，在jni.h中将其类型定义为unsigned+short。当然，这并不是相同的大小--它是2个字节而不是1个字节。这会导致底层代码出现各种问题。生成Java类型的byte[]生成jbyteArray，并将Linux上的jbyte类型定义为大小合适的signed+char|1970704|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Java_Native_Interface^0|O|4|1I|K|0|0|O|4|12|6|1W|A|2G|5|2N|5|30|E|4V|6|53|A|5N|5|62|B|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

Amazingly, I just used <code>byte</code> in Java for the first time last week, so I do have an (albeit unusual) use-case. I was writing a <a href="http://en.wikipedia.org/wiki/Java_Native_Interface" rel="noreferrer">native Java function</a>, which lets you implement a function in a library that can be called by Java. Java types need to be converted to types in the native language, in this case C

The function needed to take an array of bytes, but (forgetting about the <code>byte</code> type entirely at the time) I had it take a <code>char[]</code>. The signature Java generates for the C function gives the type of that parameter as <code>jcharArray</code>, which can be converted to a bunch of <code>jchar</code>s, which are typedef-ed in <code>jni.h</code> to <code>unsigned short</code>. Naturally, that is not the same size -- it's 2 bytes instead of 1. This caused all sorts of problems with the underlying code. Making the Java type <code>byte[]</code> resulted in a <code>jbyteArray</code>, and <code>jbyte</code> on Linux is typedef-ed to <code>signed char</code>, which is the right size

blocks|key|1970854|text|在一台字大于8位的机器上，如果你想在一个数组中存储很多8位范围内的值，那么它会有一些用处，但通常不是一个好主意，因为一个字节实际上比一个整型更容易从内存中取出。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1970855|但请记住，Java是为非常小的消费设备(机顶盒)设计的。我希望如果它在小型8位微处理器上以这种方式使用，它会更有用，因为它可以精确地适应字的大小，并且可以用于非常小规模的一般“数学”运算。|1970856|我能看到的使其有符号的唯一原因是，与int交互的无符号字节可能会有一点混乱--但我不相信它比有符号的字节更令人困惑！|1970857|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

On a machine with words larger than 8 bits it's somewhat useful if you wish to store a lot of values that fit in an 8-bit range into a single array, but typically it's not a good idea to use them otherwise since a byte is actually more effort to get out of memory than an int.

Remember though that Java was designed for very small consumer devices (set-top TV boxes). I expect if it had been used this way on small 8-bit microprocessors it would have been more useful as it would fit the word size exactly and could be used for general "Math" operations on a very small scale.

The only reason I can see to make it signed is that an unsigned byte interacting with an int can be a little confusing--but I'm not convinced it's any more confusing than a signed one is!

blocks|key|1970961|text|byte,+short,+char类型大多是无用的，除非用在数组中以节省空间。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1970962|无论是Java还是JVM都没有对它们的真正支持。几乎所有对它们的操作都会首先将它们提升到int或long。我们甚至不能写像这样的东西|1970963|short+a=1,+b=2;
a+=+a+%2B+b;++//+illegal
a+=+a+<<+1;+//+illegal|code-block|syntax|javascript|1970964|那么为什么还要费心在byte,+short,+char类型上定义操作呢？|1970965|他们所做的一切都是偷偷地扩大转换，这会让程序员感到惊讶。|1970966|entityMap^0|0|H|0|18|3|1C|4|0|0|A|H|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|10|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|14|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|R|$]]

<code>byte, short, char</code> types are mostly useless, except when used in arrays to save space.

Neither Java or JVM has any real support for them. Almost all operations on them will promote them to <code>int</code> or <code>long</code> first. We cannot even write something like

<pre><code>short a=1, b=2;
a = a + b; // illegal
a = a &lt;&lt; 1; // illegal
</code></pre>

Then why the heck even bother with defining operations on <code>byte, short, char</code> types at all? 

All they do are sneaking in widening conversions that will surprise the programmer.

blocks|key|1757412|text|byte在Java+Card的applet开发中有着广泛的应用。因为卡的资源有限，所以内存的每一位都是宝贵的。顺便说一句，卡处理器在处理整数值方面有局限性。int类型支持是可选的，不支持java.lang.String，因此所有整数操作和数据存储都是由byte和short变量和数组完成的。由于整型字面值属于int类型，因此应在整个代码中将其显式转换为byte或short。与卡的通信通过APDU命令，该命令作为byte数组传递给小应用程序，这些byte数组应该被分解为APDU，以解码命令类、指令和参数。查看以下代码，您会发现byte和short类型对Java+Card开发有多重要：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1757413|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%2B1),+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+%2B=+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]+%2B=+len;
++++++++++++++++++++}+else+{
++++++++++++++++++++++++fileSize+=+(short)+(offset[OFFSET_RECV]+%2B+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

}|code-block|syntax|javascript|1757414|entityMap^0|0|4|26|3|2L|G|3I|4|3N|5|4A|3|4W|4|51|5|5Q|4|67|4|7C|4|7H|5|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]|$9|17|A|18|B|C]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|1B|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|L|$]]

<code>byte</code> has an extensive use in applet development for Java Card. Because cards have limited resources every bit of memory is precious. By the way card processors have limitations in processing of integer values. <code>int</code> type support is optional and <code>java.lang.String</code> is not supported so all integer operation and data storage is done by <code>byte</code> and <code>short</code> variables and arrays. As integer literals are of <code>int</code> type, they should be explicitly cast to <code>byte</code> or <code>short</code> in whole code. Communication with card goes through APDU commands that is handed to applet as an array of <code>byte</code>s that should be decomposed to <code>byte</code>s to decode command class, instruction and parameters. Looking at the following code you see how much <code>byte</code> and <code>short</code> types are important to Java Card development:

<pre><code>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 &amp; 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] &amp; 0x00ff); 

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

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

 if ((cla &amp; 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 &amp; 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

}
</code></pre>

blocks|key|1971147|text|当我为J2ME编写软件和游戏时，我经常使用它。在大多数J2ME设备上，您的资源都是有限的，因此例如将级别映射存储在字节数组中比将其存储在整数数组中要占用较少的资源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1971148|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I used it frequently when I was programming software and games for J2ME. On most J2ME-devices, you have limited resources, so storing for example the map of a level in a byte-array is less resource-intensive than storing it in an int-array.

blocks|key|1757551|text|我现在在java中为一个蓝牙android项目使用bytes。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1757552|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I am using bytes right now in java for a bluetooth android project.

blocks|key|1757815|text|字节大小为8位。字节的大小有助于在执行诸如写入文件或从文件读取之类的功能时处理输入和输出。考虑一个场景，在该场景中，您希望从键盘或从任何文件读取输入。如果你使用"byte“数据结构，你知道你一次只能接收一个字符，因为它的大小是8位。因此，每次接收输入流时，您都知道实际上是一次接收一个字符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1757816|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The size of byte is 8 bits. The size of byte helps in processing input and output while performing functions like writing to a file or reading from a file. Consider a scenario in which you want to read an input from the keyboard or from any file. If you use the "byte" data structure, you know that you are receiving one character at a time since the size is 8 bits. So every time you receive an input stream, you know that you are actually receiving one character at a time.

For some inexplicable reason the <code>byte</code> primitive type is signed in Java. This mean that valid values are -128..127 instead of the usual 0..255 range representing 8 significant bits in a byte (without a sign bit).

This mean that all byte manipulation code usually does integer calculations and end up masking out the last 8 bits.

I was wondering if there is any real life scenario where the Java <code>byte</code> primitive type fits perfectly or if it is simply a completely useless design decision?

<hr>

EDIT: The sole actual use case was a single-byte placeholder for native code. In other words, not to be manipulated as a byte inside Java code.

<hr>

EDIT: I have now seen a place where an inner tight loop needed to divide by 7 (numbers 0..32) so a lookup table could be done with bytes as the datatype so the memory usage could be kept low thinking of L1 cache usage. This does not refer to the signed/unsignedness but was a case of an actual usage.

Are there any real life uses for the Java _signed_ byte primitive type?

数据存储

数据结构

编译器

Linux

Java

出于某种难以解释的原因，byte原语类型是用Java语言签名的。这意味着有效值是-128..127，而不是通常0..255范围，表示字节中的8个有效位(没有符号位)。这意味着所有字节操作代码通常执行整数计算，并最终屏蔽最后8位。我想知道，在现实生活中，有没有什么场景可以让Java byte原语类型完美匹配，或者它只是一...

问Java原语类型在实际生活中有什么用处吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java原语类型在实际生活中有什么用处吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java原语类型在实际生活中有什么用处吗？
EN