There is no byte type in the Java Virtual machineWell... How to say, personal feeling this is a bit of a bluff. Indeed, when the idea just appeared in my mind, I felt a bit of baloney, after all, how can I say that there is no byte type in the Java virtual machine?
Well, let me explain it a little bit. The basic types of Java Virtual machine operations are basically done on the stack (this is believable, because it's not what I said). We know that when Java is working on a statement, it first presses the operand to the stack, then pops it out of the stack, and then presses the result back into the stack. This is also true of any operation on byte. As a result, Java is pressed into the stack before it operates on a byte type. In fact, Java is not pushed into the stack is not a byte type, but a standard int type (32-bit, byte is 8-bit), that is, the Java Virtual machine will be our short lovely byte type into the stack before it will be elongated into an int type and then press the stack. (But actually before the stack is the int type) in this way, the byte type that we pop in the stack or from the stack is actually stored in the length of the Int. That's why I said that there is no byte type in the Java virtual machine. Because they are all turned into int.
int? Or a byte? So in the Java Virtual machine processing to deal with the 32-bit long int, then what about byte? In other words, if we see a 32-bit int, should we call it int or byte? (This sentence is a bit of a mouthful, I will change a description next time)
For this question, my personal answer is that you are the name of the shrimp. For example: Now the top of the stack is two ... Well... 32-bit long ... Well... You know what I mean. You want to add them to the calculation. At this point your role is obvious, when you say to the virtual machine and add them to me as an integer (int), then the Java Virtual opportunity pops up these two things and then adds the results to the stack with the int type. But if you say to the virtual machine: Add these two bytes to a byte or add them together into a byte, then the Java Virtual machine will still pop up the two things added, but the previous sentence will first convert them into a byte and then int, and then add, and the next sentence will be added directly. The final result of the two sentences is to convert the sum into a byte and then into an int press into the stack.
Type ConversionsSo, what about type conversions? This should always be a byte!
Unfortunately, I can only say that the type conversion process will appear in the real byte, but it does not live until the end is stretched. For example, take a look at the two meaningless codes I've found in the program that make sense:
int a = 1;
byte B = (byte) A; |
Well, I admit that the code will be written so that the program doesn't make sense to go anywhere. But we're on the same. When I first saw this, I was very excited to think that the variable B above should always be byte. If you are the same as me, then congratulations on your one step away from genius.
I can only say that the answer is negative. Not to fight against you, but indeed to deny. Yes, the second sentence did produce a byte when it was executed, but unfortunately it didn't live to the end. Eventually it was pulled into an int pressed into the stack and used as the value of byte variable B. Although it was pulled into a 32-bit int, after all, it is a byte, so the body still has the descent of byte. How to say, that is, it is the virtual machine with symbols extended out. This is a good understanding that byte itself is a 8-bit 0 or 1 combination, you are 8 bits on each bit 0 or 1 pull the longer, at best, a long long 0 or 1 of byte. So to become a 32-bit, you have to fill byte 24 in. So where do these 24 people come from? The Java Virtual machine is done from a byte sign bit (that is, the highest bit). This is called a signed extension. Take the above procedure for example, the 1 compression into byte in binary view is 00000001, this I think we are not unfamiliar. Next is the extension, our byte sign bit is positive, that is 0, then the Java Virtual machine will fill the remaining 24 bits with zeros, the result is 00000000000000000000000000000001. Count yourself to see if I missed out.
You may think that my example is a little too simple, okay, I'm a hard one. Let byte variable b equals-1. Of course, it is not simple to change from the int type of-1 to the byte type of 1, but instead to the int type of a positive integer to truncate the Java virtual machine to the byte type of-1. So what is this positive integer? To tell the truth, I took the advanced calculator for a day and finally found it on Google: 2147483647. As long as the value of a in the above statement is changed to this, the value of byte variable B will be-1. Very simple, I think there is no need to explain .... I'm sorry, I've got a little bit of a bum. Let me explain this: the binary of the 2147483647 integer is this: 01111111111111111111111111111111, carefully, 32 bits. Now we're going to force it into byte, only 8 bits, so the Java virtual machine will cut off 24 bits for us without thinking, and the remaining 8 bits are 1:11,111,111, which of course is that-1. What the? You said not? Yes-127? No no no, don't forget, the Java virtual machine uses the complement to express, you see is the complement. Let's figure this out again,-1. Well, the next step is to expand the int type. A simple copy of the symbol bit 24 out of the good, the result is 11111111111111111111111111111111. How many are these? Count yourself.
SummaryWell, with all that said, we've seen that although the operands in a Java Virtual machine can be a byte, the end result is int, whether it's an operation or a type conversion. As for the difference in the implementation process, it is up to the person who wrote the program himself. If you are ambiguous, don't expect Java virtual opportunities to understand what you mean.
Java code
- Public static String bytes2hexstring (byte[] b) {
- String ret = "";
- for (int i = 0; i < b.length; i++) {
- String hex = integer.tohexstring (b[i] & 0xFF);
- if (hex.length () = = 1) {
- Hex = ' 0 ' + hex;
- }
- RET + = Hex.touppercase ();
- }
- return ret;
- }
public static string bytes2hexstring (byte[] b) { string ret = ""; for (int i = 0; i < b.length; i++) { String hex = integer.tohexstring (b[i] & 0xFF); if (hex.length () = = 1) { hex = ' 0 ' + hex; } RET + = Hex.touppercase (); } return ret;}
Above is the byte[] conversion hex String, note here b[i] & 0xFF will be a byte and 0xFF with the operation,
Then using integer.tohexstring to get the hexadecimal string, you can see b[i] & 0xFF operation is still an int,
So why do we work with 0xFF? Direct integer.tohexstring (b[i]); Do you want to convert byte strong to int?
The answer is no.
The reason for this is:
The size of 1.byte is 8bits and the size of int is 32bits
Numeric type of 2.java: Positive numbers exist in the form of the original code in the computer, and negative numbers exist in their complement form in the computer.
First, we will review the basic theory of computer
Byte is a byte saved with 8 bits, which is 8 0, 1.
The first bit of a 8-bit is the sign bit,
Which means that 0000 0001 represents the number 1 1000 0000 Represents the 1
So the positive number is 0111 1111, which is the digit 127, the negative number is 1111 1111, which is the digit 128
This is the binary source code, but in Java is used in the form of complement, the following describes what is the complement
1, anti-code:
If a number is positive, then its inverse code is the same as the original code;
If a number is negative, then the sign bit is 1, the rest of you are the original code to take the reverse;
2, Complement: Using overflow, we can change the subtraction into addition
For decimal numbers, 5 available subtraction is obtained from 9:
9-4=5 because 4+6=10, we can add 6 as a 4 complement.
Rewrite for addition:
9+6=15 (minus the high 1, which is 10) gets 5.
For hexadecimal numbers, the subtraction from C to 5 is available:
C-7=5 because 7+9=16 will be 9 as a complement of 7
Rewrite for addition:
C+9=15 (minus the high 1, which is 16) gets 5.
In the computer, if we use 1 bytes to represent a number, one byte has 8 bits, more than 8 bits go into 1, in memory the case is (100000000), carry 1 is discarded.
⑴ A number is positive, then its original code, anti-code, the same complement
⑵ a number is negative, the complement is: negative value of the absolute inverse code plus 1
-1 of the original code is 10000001
-1 of the anti-code is 11111110
+ 1
-1 of the complement is 11111111
The original code: 0000 1010 Its storage in the computer is 0000 1010,
-10 Absolute value : 0000 1010 Anti-code: 1111 0101 plus 1:1111 0110, this is-10 complement,
OK, 1111 0110 in the computer is representative-10.
128 binary representation of absolute value 128:1000 0000 Bitwise counter 0111 1111 plus 1:1000 0000,
Which means 128 is 1000 0000 in the computer,
The integer.tohexstring parameter is int, and if you do not &0xff, then when a byte is converted to int,
Since int is 32 bits, and byte has only 8 bits, this will be the complement.
For example, the decimal number of the complement 11111111 is 1 to int when converted to 11111111111111111111111111111111 many 1 ah, hehe!
That is 0xFFFFFFFF but this number is wrong, and this complement will cause errors. and 0xFF and after the high 24 bits will be cleared 0, the result is right.
Java
A byte in Java whose range is -128~127, and the integer.tohexstring parameter is an int,
If &0xff is not performed, then when a byte is converted to int, a bit extension is done for negative numbers.
For example, a byte-1 (that is, 0xff) will be converted to an int of-1 (i.e. 0xFFFFFFFF), then the result of conversion is not what we want.
And 0xFF is the default is shaping, so, a byte with 0xFF to join the first to convert that byte into a shaping operation,
In this way, the high 24 bits in the result will always be cleared 0 , and the result is always the one we want.
BYTE type it differs from int byte size to 8 bits (that is, an integer representing from (-128 ~ 127) that is ( -2^8--2^8-1) int size 32 bits indicates the range is " -2^32" to "2^32-1";
That is, "2147483648" to "2147483647";
Java Core Knowledge Point-byte Detailed
