We Keep Coding

Double to Int without lossy precision

The following declaration gives me a compile-time error "Error:(19, 13) java: incompatible types: possible lossy conversion from double to int"
int i1 = 10.0;
// Error:(19, 14) java: incompatible types: possible lossy conversion from double to int
Question 1
I understand the error but can the compiler not infer - in this particular case - that there will be no loss of precision?
Question 2
If I explicitly convert the double to an int then it compiles fine (not even a warning) even though I am definitely losing precision in this example
int i2 = (int)9999999999999.999999999;
If I can't compile the first case - where no loss occurs - then why does this second example with the explicit conversion not even generate a compiler warning?

In theory, a compiler could infer that the specific example in #1 wouldn't actually loose precision based on the literal's value, but as you've seen - it doesn't.
The explicit cast signals to the compiler that you are aware of the situation an handling it, so the code actually compiles. Most IDEs, however, could be configured to emit a warning in such a situation too.

The assignment of a double value to an int variable would require a narrowing conversion, even if the value is a compile-time constant, and hence requires an explicit cast.
Except that an int (or short or char) constant value can be assigned to a byte, short, or char variable without casting, if the constant actually fits in the variables value range, as explicitly documented in the Java Language Specification, section 5.2. Assignment Contexts:
Assignment contexts allow the value of an expression to be assigned (§15.26) to a variable; the type of the expression must be converted to the type of the variable.
Assignment contexts allow the use of one of the following:
an identity conversion (§5.1.1)
a widening primitive conversion (§5.1.2)
a widening reference conversion (§5.1.5)
a boxing conversion (§5.1.7) optionally followed by a widening reference conversion
an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion.
If, after the conversions listed above have been applied, the resulting type is a raw type (§4.8), an unchecked conversion (§5.1.9) may then be applied.
In addition, if the expression is a constant expression (§15.28) of type byte, short, char, or int:
A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable.
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.

Answer to question 1
There is a loss of precision according to the compiler, because the compiler only sees that you have an int variable on the left and a double value on the right. The compiler is not so smart as to figure out that 10.0 will not lose precision when converted to an int.
The compiler could in theory be built to allow that statement to compile, but there is no real benefit in doing so. Almost no one writes int x = 10.0.
Answer to question 2
Indeed, there is a loss of precision, but why did the compiler not complain? Because you used a cast. You wrote (int). This is you showing the compiler that you know what you're doing. By writing a cast, you are telling it that you are aware that there is a possible loss of precision.

Interesting question
In theory this could be possible, well javac does not complain when doing:
short s = 12;
Even if 12 here is a compile time constant of type int, so it can deduce that no precision is lost. I guess this is what the compiler team thought would be most appropriate.
Well when you cast is a different story, it's like saying "trust me, I know what I'm doing", even if you loose precision.

How does Java handle precision across multiple types?

In Java when I print something like this
System.out.println(1.0f*1l));
I get an output of
1.0
or with
System.out.println(((byte)1)*'A');
I get an output of
65
In both cases, one of the types is bigger than the other. Longs are 64-bits while floats are 32-bits, and bytes are 8-bits while chars are 16-bits. Despite this, Java outputs the result in the smaller type. Wouldn't this be considered a loss of precision?

Java Language Specification provides a list of rules governing the type of result based on the types of operands.
In particular, section 4.2.4 says that
If at least one of the operands to a binary operator is of floating-point type, then the operation is a floating-point operation, even if the other is integral.
which explains why float "wins" against a long.
Integer arithmetic is explained in section 5.6.2. Specifically, it says that
Widening primitive conversion (§5.1.2) is applied to convert either or both operands as specified by the following rules:
• If either operand is of type double, the other is converted to double.
• Otherwise, if either operand is of type float, the other is converted to float.
• Otherwise, if either operand is of type long, the other is converted to long.
• Otherwise, both operands are converted to type int.
That is why in your second example the result, 65, is of type int.

Java widens type based on the range of possible values. This means float is considered wider thanlong.
Also integer operations which are not long are performed as int.
A byte * char is an int

You are asking about Binary Numeric Promotion (JLS 5.6.2) (emphasis mine):
When an operator applies binary numeric promotion to a pair of operands, each of which must denote a value that is convertible to a numeric type, the following rules apply, in order:
If any operand is of a reference type, it is subjected to unboxing conversion (§5.1.8).
Widening primitive conversion (§5.1.2) is applied to convert either or both operands as specified by the following rules:
If either operand is of type double, the other is converted to double.
Otherwise, if either operand is of type float, the other is converted to float.
Otherwise, if either operand is of type long, the other is converted to long.
Otherwise, both operands are converted to type int.
The expression 1.0f*1l is a float and long, so the long is converted to a float.
The expression ((byte)1)*'A' is a byte and a char, so they are both converted to int.

In addition to the other answers that spell out the rules in detail, I think it's also worth considering why it should be this way. Suppose you do
2.7F * 2L
The true mathematical answer to this multiplication is 5.4. Therefore if the answer were a long, it would have to be 5L (5 is the closest integer to 5.4). Because of this kind of thing it makes much more sense for the result of multiplying a floating-point value by an integer to be a floating point value. I think there would be many more questions about this on Stack Overflow if the following line of code printed 5.
System.out.println(2.7F * 2L);
In fact it prints 5.4.
It also makes sense that all operations between integer types (except long) are done with int. After all, a byte is usually thought of as a small packet of data, and a char is usually thought of as a character. From these perspectives multiplying byte or char values isn't really meaningful. It makes much more sense to keep the rules simple and just do the operations with int.

Does Java always convert addition result into int?

is it true that java converts primitive Type addition (like byte+short) results into integers?

I suspect you are talking about promotion. Its not as simple as always promoting to an int. Section 5.1.2 talks about primitive widening in detail, but here are a few guidelines:
If the result is assigned to a variable then it will be promoted to the type of the variable (if possible)
A more limited type will be promoted to the more expansive type
A result can be promoted if it is likely to be larger than the type will handle
Like I said this is a simplification of the actual rules, but in general Java does the right thing.

The following sections of the Java Language Specification (JLS) are applicable:
Section 5.6 Numeric Promotions) "Numeric promotion is applied to the operands of an arithmetic operator"
Section 5.6.2.2 Binary Numeric Promotion) "...If either operand is of type double...long...float...Otherwise both operands are converted to type int"
So in your example of byte + short, the operands would each first be converted to ints.
To further illustrate:
short a = 1;
short b = 2;
short c = a + b;
will produce a compile error "required short, found int".
You would need to cast the result of the addition (an int) to a short, like this:
short c = (short) (a + b);

You need to know about argument promotion and casting concept.
Java can only evaluate the expressions which have values of the same type. for example if you have the expression a = b + c; then a and b and c must have the same type. you now might wonder so how you can add up an integer and a double without anything goes wrong. this is where the concept of type promotion is applied implicitly by Java. in this case your integer variable is implicitly changed to double only for performing your operation (remember the type of your integer variable is not changed only a double copy is made for your expression).
Now the point is that java only uses type promotion implicitly if the data of your variable is not lost. For example if you change integer to double you will not lose any data. but if you want to change let's say a double variable with value 1.2 to integer then you will lose the fraction part. This is where java will not apply type promotion and you need to do type casting manually. Basically what type casting means is to take control over the compiler and telling to compiler that I know I might lose some data in my variable but it is ok and perform the casting for me.
Type promotion and casting occur in expressions and in method calls.
The table below shows the valid promotions which java would do automatically.
Type Valid Promotion
double None
float double
long float or double
int long, float or double
char int, long, float or double
short int, long, float or double (but not char)
byte short, int, long, float or double (but not char)
boolean None(boolean values are not considered to be numbers in java)

Java widening conversions

I'm preparing for Java 7 certification and have the following question.
Byte b = 10 compiles ok. Looks like the compiler is narrowing int 10 to byte 10 and then boxing it. How come Byte b = new Byte(10) won't compile? Why can't the compiler narrow int 10 to byte 10 like it did in the first case?
Also how come Long l = new Long(10) compiles ok but Long l = 10 fails?
I'm not clear about how this works. Can somebody provide an clear explanation?

Section 5.2 of the JLS covers the types of conversions that are allowed in assignment contexts.
Assignment contexts allow the use of one of the following:
an identity conversion (§5.1.1)
a widening primitive conversion (§5.1.2)
a widening reference conversion (§5.1.5)
a boxing conversion (§5.1.7) optionally followed by a widening reference conversion
Additionally,
In addition, if the expression is a constant expression (§15.28) of type byte, short, char, or int:
A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable.
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.
Byte b = 10 compiles ok because 10 is a constant expression and is representable as a byte.
Byte b = new Byte(10) won't compile because 10 is an int literal, and method invocation conversion won't perform primitive narrowing conversions. To get this call to a Byte constructor to compile, you can explicitly cast 10 to byte:
Byte b = new Byte( (byte) 10);
Long l = new Long(10) compiles because method invocation conversion will perform primitive widening conversions, including from int to long.
Long l = 10 won't compile, because Java will not specifically allow a widening conversion followed by a boxing conversion, as I discussed in a recent answer. To get this to compile, you can use a long literal, so only boxing is necessary.
Long l = 10L;

The basic rules are:
you can't convert-and-autobox in one step (JLS 5.1.7 defines the boxing conversions, and it doesn't include convert-and-autobox type conversions, so they're not allowed)
you can't implicitly narrow a type
These rules explain why Long l = 10 doesn't work, as well as new Byte(10). The first would require the int literal 10 to be widened to a long and then be boxed, which isn't allowed. (More precisely, it would require a conversion from int to Long, which JLS 5.1.7 doesn't define.) The second would require the int literal 10 to be implicitly narrowed to a byte, which isn't allowed.
But there are exceptions to the rule. Byte b = 10 is explicitly allowed by JLS 5.2:
In addition, if the expression is a constant expression (§15.28) of type byte, short, char, or int:
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.
(some irrelevant parts omitted)
Lastly, new Long(10) works because the int literal 10 can be automatically widened to a long 10L.

Byte constructor takes either byte type or String type. See this
Constructor for Long takes long as an argument. Since long can take in integer, it allows it in the constructor.

10 is an integer literal, you have to downcast it to pass it to the Byte constructor. There unfortunately is no byte literal syntax to remove the cast either.
Also how come Long l = new Long(10) compiles ok but Long l = 10 fails?
Because 10, an integer, can fit into a long with no issues. An integer cannot fit into a byte, so the cast is needed in that case (widening conversion).
This cast is compile time as well, as it's also a widening conversion. Check out section 5.1.5 in the JLS:
Widening reference conversions never require a special action at run time and therefore never throw an exception at run time. They consist simply in regarding a reference as having some other type in a manner that can be proved correct at compile time.

i think i have a solution for your problem...
//constructor for Byte class
Byte(byte value){
}
There are two rules for java type conversion
Both types are compatible
Destination type is greater than source type
Now in Your case you trying to convert int into byte which is against our second rule....
but below is the solution
Byte b = new Byte((byte)10);
Now let's talk about your Second issue...
Long x = 10;//incompatible type
This is the issue of autoboxing...
Now as we all know that autoboxing automatically converted primitive type into it's wrapper class..
But conversion not happens in case of autoboxing means....int is converted into Integer
byte is converted into Byte..
Now when you assign int primitive type to Long, it gives you error of incompatible type.......
Solution
Long x = (long) 10;//works fine....

Wrapper classes - why integer literals fail for Long but work for anything smaller

Just trying to understand auto-boxing, which I do apart from one thing:
Short s = 250;
Long l = 250;
The assignment to Long l fails. This, I expect, is because you cannot widen then box (i.e. it tries to widen the int value 250 to a long and then box it which it cannot do).
However, the assignment to Short s works. What is going on to make this fine? My assumption was it is still doing boxing and some kind of conversion. But if it's a case of it knowing 250 fits into a short, why does it not know that 250 will fit into a long?

Normally, you cannot apply multiple (implicit) conversions in assignment (JLS §5.2 Assignment Conversion):
Assignment conversion occurs when the value of an expression is assigned (§15.26) to a variable: the type of the expression must be converted to the type of the variable. Assignment contexts allow the use of one of the following:
an identity conversion (§5.1.1)
a widening primitive conversion (§5.1.2)
a widening reference conversion (§5.1.5)
a boxing conversion (§5.1.7) optionally followed by a widening reference conversion
an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion.
Long l=250; requires two conversions (widening primitive conversion followed by boxing conversion), that's why it doesn't compile.
Long l=250l; compiles because it requires a single boxing conversion.
But narrowing conversion of a constant expression is a special case, that's why Short s=250; compiles:
In addition, if the expression is a constant expression (§15.28) of type byte, short, char or int :
A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable.
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.

Ideally, no auto narrowing should be allowed.
But since there are no byte/short literals, we can't write
byte b = 0b;
and it seems silly to
byte b = (byte)0;
so auto narrowing of constant integer is allowed so we can write
byte b = 0;
which is carried over to autoboxing case.
For long/Long, since there are long literals, this is less of a problem. Still, it should be allowed, since auto widening of signed integer is always safe.