THE JAVA TYPE CASTING BUG –YOU’VE PROBABLY OVERLOOKED

“A deep dive into how silently casting a long to float or double in Java can cause unexpected rounding — even when it looks like everything's working fine.”

While I was experimenting with Java's primitive data types, I stumbled across a strange behavior when casting a long value to a float. Initially, everything looked fine — until I tried a slightly different number. Let's dive into what I found!

---

🧪 The Case: Casting long to float

Here’s a small Java snippet that caught my attention:

class Example {
    public static void main(String args[]) {
        long original = Long.MAX_VALUE; // 9223372036854775807
        float x = original;
        long y = (long)x;
        System.out.println("Original : " + original);
        System.out.println("After storing the long value as float : " + x);
        System.out.println("Stored in float and cast back : " + y);
        System.out.println("Same? " + (original == y));
    }
}

Original : 9223372036854775807
After storing the long value as float : 9.223372E18
Stored in float and cast back : 9223372036854775807
Same? true

Looks good, right? Now let’s subtract just 1 from that original value:

class Example {
    public static void main(String args[]) {
        long original = Long.MAX_VALUE - 1; // 9223372036854775806
        float x = original;
        long y = (long)x;
        System.out.println("Original : " + original);
        System.out.println("After storing the long value as float : " + x);
        System.out.println("Stored in float and cast back : " + y);
        System.out.println("Same? " + (original == y));
    }
}

Original : 9223372036854775806
After storing the long value as float : 9.223372E18
Stored in float and cast back : 9223372036854775807
Same? false

---

🤔 What Just Happened?

float in Java is a 32-bit IEEE 754 floating-point number — it simply can’t hold the full precision of a 64-bit long (which has a 53-bit mantissa in double-precision, and only ~24 bits in single-precision).

So when you convert a long to float, you lose precision — and in some edge cases, this causes rounding to the nearest representable float, which might increase the number unexpectedly.

In our second example, 9223372036854775806L was rounded up to the same float representation as Long.MAX_VALUE — so when cast back to long, it became greater than it originally was.

---

🔍 Key Takeaways

✅ float cannot safely store large long values without precision loss.
⚠️ Be careful when comparing values after type casting.
💡 Use double or BigDecimal if you need more precise conversions or arithmetic.

---

🎯 Real-World Impact

Such subtle bugs can appear in:

• Financial applications dealing with large monetary values
• Timestamps or IDs stored as long
• Scientific calculations where precision matters Always know your data types and limits before relying on direct conversions.

---

💬 Final Thoughts

This tiny experiment reminded me why understanding the limits of data types is crucial, even in the simplest programs. Java makes type casting easy — but sometimes too easy!

Have you encountered similar surprises in Java (or other languages)? I’d love to hear your thoughts in the comments.

Let’s keep learning, one line at a time! ✨

---

📣 Follow me on LinkedIn and GitHub for more Java insights and development experiments.