# A Java Conversion Puzzler: Understanding Implicit Casting and Overflow

DevFeed: [A Java Conversion Puzzler: Understanding Implicit Casting and Overflow](<https://devfeed.tech/articles/a-java-conversion-puzzler-understanding-implicit-casting-and-overflow-30739.md>)

Original publisher: [Read original article](<http://blog.vanillajava.blog/2024/12/a-java-conversion-puzzler-understanding.html>)

Author: Peter Lawrey (noreply@blogger.com)

Published: 2024-12-07T22:23:00Z

Content type: article

Language: en

Sources: [Vanilla Java](<https://devfeed.tech/sources/vanilla-java.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [floating-point](<https://devfeed.tech/topics/floating-point.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [critical](<https://devfeed.tech/tags/critical.md>), [exercise](<https://devfeed.tech/tags/exercise.md>), [floating-point](<https://devfeed.tech/tags/floating-point.md>), [info](<https://devfeed.tech/tags/info.md>), [java](<https://devfeed.tech/tags/java.md>), [performance](<https://devfeed.tech/tags/performance.md>), [puzzles](<https://devfeed.tech/tags/puzzles.md>)

## AI overview

This article explains a Java conversion puzzle involving compound assignment, implicit casting, floating-point rounding, and integer overflow. It shows why adding 0.0f can produce different results for int and long values, including a conversion to Integer.MIN_VALUE when the rounded value is cast back to int.

## Source excerpt

This article explores a subtle Java conversion puzzle that challenges assumptions about how arithmetic operations, implicit casting, and floating-point conversions interact. Inspired by complexities often encountered in low-latency and high-performance environments, it demonstrates why a keen understanding of Java's type system is essential for building reliable and efficient applications. Introduction The following example demonstrates a scenario where an innocuous-looking arithmetic operation leads to a surprising result. While such questions are rare and arguably impractical, they highlight subtle behaviours that can affect correctness and performance, especially in critical systems like high-frequency trading platforms or complex data-processing pipelines. The Problem: A Surprising Print Statement Consider the following code: int i = Integer.MAX_VALUE; i += 0.0f; int j = i; System.out.println(j == Integer.MAX_VALUE); // true At first glance, one might assume that adding 0.0f to an int should not change its value. Indeed, the output true reinforces this notion. However, if you change int i for long i, things get weird: long i = Integer.MAX_VALUE; // only the type of i is changed i += 0.0f; int j = (int) i; System.out.println(j == Integer.MAX_VALUE); // false System.out.println(j == Integer.MIN_VALUE); // true What is going on, you might wonder? Let me start by explaining why using a long gives such a strange result. Understanding the Implicit Casting The key detail lies in how Java handles the += operator. It is not strictly equivalent to a = a + b; but rather: a += b; has a subtle difference which most of the time doesn't matter: // has an implicity cast here a = (typeOf(a)) (a + b); Another subtle feature of addition is that the result is the "wider" of the two types. This means that: i += 0.0f; is actually: i = (int) ((float) i + 0.0f); // or i = (long) ((float) i + 0.0f); The result of (float) i can be imprecise due to floating-point rounding. A float has a 2