Enthuware

The right answer (double only) follows an explanation:
"There is no need for analyzing the whole code. XXX amount = 1000.0; will be valid only if XXX is double."

Could you elaborate on float and double, I thought float is valid too. Seems I am missing something important.

When you write a floating point number without 'f', it is considered a double. In this case, 1000.0 is actually a double and not a float, so it can't be assigned to a variable of type float. To assign it to a float variable, you need to write 1000.0f or 1000.0F
HTH,
Paul.

Wow, didn't know that. Thank you

Yes but wouldn't it implicitly promote the float to a double?

Same as if you wrote:
double i = 1;

kecker wrote:Yes but wouldn't it implicitly promote the float to a double?

Same as if you wrote:
double i = 1;

It is not clear what you mean.
Do you mean float amount = 1000.0; ?
If so, as explained above, 1000.0 is a double, which is bigger than float. Implicit promotion happens from smaller to bigger, not the other way round.

Ok I think that answers my confusion.

Isn't it an infinite loop?

Yes, it is Although not relevant to the question but it should be i++ instead of t++.

Within the loop: I thought that arithmetic operations like these all implicitly cast the variables to ints.
Even though an int fits into a double... it doesn't store any decimals. Don't you lose precision by performing an operation like this?

int doesn't have any decimals, so why do you think assigning it to a double will lose precision?

if a division is implicitly casted to an int then the following block of code is equal to the one up above However, 10.0/3.0 = 3.33 and the implicit cast would make the outcome 3...thus assigning the loss of precision happens during the implicit cast from double to int.

I am not sure I understand your question. The two blocks are not equivalent. The first one is a division involving doubles. There is no implicit cast to int there. The value of x/y in this case is a double.
In second, by applying (int), you are doing an explicit cast. You are telling the compiler that you are fine with losing the value after decimal.

Regarding implicit casting from small to big: long (64bit) --> float(32bit) is working fine.

long l = 1_000_000_000;
float f = l;

Why does this code work?

Because as per section 5.1.2 of JLS, it is permitted.
The JLS does not mention the reason so one can contemplate about the reasons. There are many such cases where an an argument can be made for or against allowing or disallowing something. Ultimately, the language designers have to take a call after weighing all the arguments.
We try to form some logical explanation to make it easy to remember the rule in our mind so that we can answer questions in the exam, but ultimately, in many cases, the reason is simply because the JLS says so

HTH,
Paul.