0

I have started studying JAVA . In there,

byte ch=50;
ch*=2;

works fine. But

byte ch=50;
ch=ch*2;

does not. error:possible loss of precision required:byte found:int

Why this do not happen in 1st case.

2 Answers 2

3

The second case contains a general multiplication expression, which is of type int, and assignment of int to byte doesn't work because information loss could occur (there are many more ints than bytes).

But the first one contains only a *= operator, and that operator is well-defined for any input value, so no loss occurs. The trick is that byte is defined to "wrap around" when you exceed its range via arithmetic, so a technically correct (although not very useful) result can be computed.

In other words, loss still occurs, but since it's defined to occur in the language definition, the compiler doesn't complain. (There is a hint in the specification, that says the result of the binary operation is converted to the type of the left-hand variable, Java Specification 1.7) There is no such rule defined for assignment; assigning 12345 to a byte does not silently result in Byte.MAX_VALUE, instead it's simply a type error.

And why were things done that way? Because all obvious alternatives would have been worse! If integer arithmetic didn't wrap around, it would have to throw an exception (bad), or yield undefined results (very bad), or it would have to be disallowed unless the compiler could prove that overflow will not occur (basically impossible to guarantee). So we took silent wrapping as the least bad alternative.

But with assignment we can use the strong type system to catch all possible overflow situations and allow most reasonable uses, so that option was chosen.

2
  • Basically, I think the creators of Java decided that it would be useful require cluttering code with typecasts when storing into byte variables anything other than the contents of other byte variables, but when they discovered that the arithmetic promotion rules would render the compound operators useless with such variables, they dropped the restriction in that case so as to make such variables useful. Personally, I think Java would have been simpler and better if they had left out byte, short, and maybe char as types, but included native methods to fetch and store...
    – supercat
    Commented May 27, 2015 at 15:43
  • ...items of any integer type to/from an integer array. Within the JVM there is no difference among any of the shorter-than-int types except that before storing a value to a variable of such a type the JVM adds instruction to sign-extend the lower portion of a word into the upper portion. From a language perspective, the only ability one would lose if all variables of type byte were replaced with int would be the ability to store a byte variable directly into a byte[] array slot without a typecast--an ability that could be added via storeByte method.
    – supercat
    Commented May 27, 2015 at 15:47
-1

don't follow any answer above,I will give u definite answer: Java Has a concept called auto Promotion. See below Example: bye is 8 bits, so, maximum range of byte value is : 2^8 =256. Its -128 to -1 and 0 to 127. Example: if byte a=100,b=28; both are valid but byte sum=a+b; // it will result 128 which is not in byte range. that's why , compiler automatically converts byte into int. int is 32 bits. so,2^32 is very large range of value which can hold results which byte cannot hold.

java focus more on data. Java won't allow data loss unlike c/c++ without user knowledge.

This concept is called auto promotion.

auto promotion is done to byte,short and char also. You try to add characters,it will give error this way.

above program,you can write like this:

byte ch=50; int ch=ch*2;//ch is treated as int and 2 is also considered integer literal.

since: 50 * 2 is 100, still in byte range, you can do typecasting here, but is risky since value of ch can be modified. it will work: like this: byte ch=50; byte ch=(byte)(ch*2);// manual type casting

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.