I currently read from a ByteBuffer a short value and apply it to an int.
byte[] data = new byte{0x90, 0xAF};
ByteBuffer b = ByteBuffer.wrap(data);
int value = b.getShort();
but the value contains now 0xFFFF90AF and not 0x90AF.
My solution is to bitmask the value by 0xFFFF: int value = b.getShort() & 0xFFFF;
I thought that a upcast is always possible, because short is smaller than int. Can someone explain why it behaves like this?
short is signed, and that is preserved when casting to int. 0x90AF is a negative short, so the result is negative int. Your solution of masking it is correct.
short is a signed quantity, but you are in luck: there is also char, which is the only unsigned primitive type in Java, and is the same size as short. Try to use
int value = b.getChar();
It is an often neglected fact that char is a full-blown numeric type in Java; it is only its string representation which betrays its special status.
Related
If I write something like this
System.out.println(18);
Which type has the '18'?
Is it int or byte?
Or doesn't it have a type yet?
It can't be int, because something like this is correct:
byte b = 3;
And this is incorrect:
int i = 3;
byte bb = i; //error!
EDIT:
I think I found the right part in the spec at Assignment Conversion :
The compile-time narrowing of constants means that code such as:
byte theAnswer = 42;
is allowed. Without the narrowing, the fact that the integer literal 42 has type int would mean that a cast to byte would be required:
byte theAnswer = (byte) 42; // cast is permitted but not required
This
18
is known as an integer literal. There are all sorts of literals, floating point, String, character, etc.
In the following,
byte b = 3;
the literal 3 is an integer literal. It's also a constant expression. And since Java can tell that 3 fits in a byte, it can safely apply a narrowing primitive conversion and store the result in a byte variable.
In this
int i = 3;
byte bb = i; //error!
the literal 3 is a constant expression, but the variable i is not. The compiler simply decides that i is not a constant expression and therefore doesn't go out of its way to figure out its value, a conversion to byte may lose information (how to convert 12345 to a byte?) and should therefore not be allowed. You can override this behavior by making i a constant variable
final int i = 3;
byte bb = i; // no error!
or by specifying an explicit cast
int i = 3;
byte bb = (byte) i; // no error!
The JLS-4.2.1 - Integral Types and Values
The values of the integral types are integers in the following ranges:
For byte, from -128 to 127, inclusive
For short, from -32768 to 32767, inclusive
For int, from -2147483648 to 2147483647, inclusive
For long, from -9223372036854775808 to 9223372036854775807, inclusive
For char, from '\u0000' to '\uffff' inclusive, that is, from 0 to 65535
And JLS-3.10.1 - Integer Literals
An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (§4.2.1).
Finally, JLS-3.10.2 - Floating-Point Literals includes
A floating-point literal is of type float if it is suffixed with an ASCII letter F or f; otherwise its type is double and it can optionally be suffixed with an ASCII letter D or d (§4.2.3).
As for byte b = 3; it is a Narrowing Conversion from int to byte.
As stated by others, it's an integer literal.
Under the hood, it appears Java was written for 32 bit processors.
An integer is between +/- ~2.147 million, which is 2^31 with a signage bit.
So whether you're writing a bit or a full int, it's a single processor function, therefore a single memory allocation.
I have a question about the promotion of primitive types in Java. As we can see in the following example, one of the methods does not compile due to an error of type mismatch. Each method returns the same value but in different types.
The version of primitive long method works without error while the version of wrapper class Long fails. This is because the int literal in the return statement will be first promoted to a broader primitive type (e.g. long) and then to the corresponding wrapper class Integer and so on. Since Integer is not a subclass of Long the compiler gives an error.
But why does the version of wrapper class Byte works without any error? What exactly does the compiler do at this point?
long getPrimitiveLong() {
return 12; // valid
}
Long getWrapperLong() {
return 12; // Error: type mismatch
}
Byte getWrapperByte() {
return 12; // valid
}
The version with Byte works through some compiler magic.
Unlike long numeric literals which can be constructed with a L suffix, e.g. 12L, there is no such thing as a byte literal. That is why Java compiler treats numeric literals that fit in a byte as byte literals. Hence, 12 in your last example is considered a constant of type byte.
Java Language Specification offers a description of this conversion in section 5.2:
A narrowing primitive conversion followed by a boxing conversion may be used
if the type of the variable is:
Byte and the value of the constant expression is representable in the type byte.
Short and the value of the constant expression is representable in the type short.
Character and the value of the constant expression is representable in the type char.
This is because Java allows 1 conversion or Autoboxing, not more.
Java can do all these:
int i = 5;
double d = i; // int to double
long l = i; // int to long
long l = d; // double to long
Or autobox:
Integer i = 5; // int to Integer
Double d = 5.0; // double to Double
Long l = 5L; // long to Long
Converting twice, say int to Double, gives Java a hard time.
number like 12 consider as int by default by the compiler that is why the error
To fix that you can use casting for byte and place L after the value of long variable.
Read following post for more details
http://javaseeeedu.blogspot.com/2015/12/casting-part-1.html
As a short answer - try to replace 12 with 128 (byte is in range -128 to 127).
It won't compile, right?
The outcome here is that the compiler knows about byte boundaries.
For the in-depth answer you can do a deep dive into OpenJDK.
I have an integer used to seed my for loop:
for(int i = 0; i < value; i++)
Within my for loop I am seeding a byte array with byte content values that increment +1. For instance new byte[]{0x00}; But the 0x00 needs to be 0x01 on the next iteration, how can I convert my value of integer i into a value of byte in the 0x00 format?
I tried things like Byte.valueOf(Integer.toHexString(i)) but this just gives me a value that looks like 0 instead of 0x00.
new byte[]{0x00}
is actually equivalent to
new byte[]{0}
The 0x00 notation is just an alternative way to write integer constants, and if the integer constant is in the range -128 to 127, then it can be used as a byte.
If you have an existing integer variable that you want to use, and its value is in the range -128 to 127, then you just have to cast it:
int i = 1;
new byte[]{(byte)i};
I think the real problem is that you are confused about number representations and text renderings of numbers. Here are some key facts that you need to understand:
The byte type is the set of integral values from -128 to +127.
All integral types use the same representation (2's complement). The difference between the different types is their ranges.
When you "see" a number, what you are seeing is a rendering of the number into a sequence of characters. There are MANY possible renderings; e.g. the number represented in memory as 00101010 (42) can be rendered as "42" or "+42" or "0x2a" or ... "forty two".
The default format for rendering a byte, short, int and long is the same; i.e. an optional minus sign followed by 1 or more decimal digits (with no zero padding). If you want to see your numbers formatted differently, then you need to do the formatting explicitly; e.g. using String.format(...).
So to pull this together, if you want the bytes to look like 0x00 and 0x01 when you output or display them, you need to format them appropriately as you output / display them. In your example code, I doubt that there is anything wrong with the numbers themselves, or with the loop you are using to populate the array.
You are confusing the string representation of the value with the value itself. A value can be represented as binary, decimal, or hex, but it is still the same value.
If you want to use your integer to initialise a byte array, you just need to cast your integer value to a byte value as follows:
arr[i] = (byte) i;
You want
new byte[]{(byte)i}
How you print this array is another matter. Look up printf in the API reference.
I would just like to note that 0 is NOT the same thing as 0x00. If i were to use:
ColorChooserOutputText.append(Integer.toHexString(list[i].getRed()));
ColorChooserOutputText.append(Integer.toHexString(list[i].getGreen()));
ColorChooserOutputText.append(Integer.toHexString(list[i].getBlue()));
and wanted to return the color, Purple it would return: ff0cc Which would be fine if I were just using Java. But if you are going between Java and something that had format specific needs ff0cc would not produce purple.. ff00cc is actually purple.
//Declare some variables.
Color HexColor = JButton1.getBackground();
String MyRValue = null;
String MyGValue = null;
String MyBValue = null;
//Get Hex Value
MyRValue = Integer.toHexString(HexColor.getRed());
MyGValue = Integer.toHexString(HexColor.getGreen());
MyBValue = Integer.toHexString(HexColor.getBlue());
//Make sure to keep both 0's
MyRValue = ("00"+MyRValue).substring(MyRValue.length());
MyGValue = ("00"+MyGValue).substring(MyGValue.length());
MyBValue = ("00"+MyBValue).substring(MyBValue.length());
//Format your HexColor to #00ff00, #000000, #ff00ee
JTextArea1.append("#");
JTextArea1.append(MyRValue+MyGValue+MyBValue);
JTextArea1.append(", ");
String.Format ("%02x") is your friend :)
http://download.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html
http://www.xinotes.org/notes/note/1195/
Primitive Data Types - oracle doc says the range of long in Java is -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.
But when I do something like this in my eclipse
long i = 12345678910;
it shows me "The literal 12345678910 of type int is out of range" error.
There are 2 questions.
1) How do I initialize the long with the value 12345678910?
2) Are all numeric literals by default of type int?
You should add L: long i = 12345678910L;.
Yes.
BTW: it doesn't have to be an upper case L, but lower case is confused with 1 many times :).
You need to add the L character to the end of the number to make Java recognize it as a long.
long i = 12345678910L;
Yes.
See Primitive Data Types which says "An integer literal is of type long if it ends with the letter L or l; otherwise it is of type int."
You need to add uppercase L at the end like so
long i = 12345678910L;
Same goes true for float with 3.0f
Which should answer both of your questions
To initialize long you need to append "L" to the end.
It can be either uppercase or lowercase.
All the numeric values are by default int. Even when you do any operation of byte with any integer, byte is first promoted to int and then any operations are performed.
Try this
byte a = 1; // declare a byte
a = a*2; // you will get error here
You get error because 2 is by default int.
Hence you are trying to multiply byte with int.
Hence result gets typecasted to int which can't be assigned back to byte.
can you increment a hex value in Java? i.e. "hex value" = "hex value"++
It depends how the hex value is stored. If you've got the hex value in a string, convert it to an Integer, increment and convert it back.
int value = Integer.parseInt(hex, 16);
value++;
String incHex = Integer.toHexString(value);
Short answer: yes. It's
myHexValue++;
Longer answer: It's likely your 'hex value' is stored as an integer. The business of converting it into a hexadecimal (as opposed to the usual decimal) string is done with
Integer.toHexString( myHexValue )
and from a hex string with
Integer.parseInt( someHexString, 16 );
M.
What do you mean with "hex value"? In what data type is your value stored?
Note that int/short/char/... don't care how your value is represented initially:
int i1 = 0x10;
int i2 = 16;
i1 and i2 will have the exact same content. Java (and most other languages as well) don't care about the notation of your constants/values.
Yes. All ints are binary anyway, so it doesn't matter how you declare them.
int hex = 0xff;
hex++; // hex is now 0x100, or 256
int hex2 = 255;
hex2++; // hex2 is now 256, or 0x100
The base of the number is purely a UI issue. Internally an integer is stored as binary. Only when you convert it to human representation do you choose a numeric base. So you're question really boils down to "how to increment an integer?".