ChatGPT解决这个技术问题 Extra ChatGPT

Safely casting long to int in Java

What's the most idiomatic way in Java to verify that a cast from long to int does not lose any information?

This is my current implementation:

public static int safeLongToInt(long l) {
    int i = (int)l;
    if ((long)i != l) {
        throw new IllegalArgumentException(l + " cannot be cast to int without changing its value.");
    }
    return i;
}
Two code paths. One is legacy and needs ints. That legacy data SHOULD all fit in an int, but I want to throw an exception if that assumption is violated. The other code path will use longs and won't need the cast.
I love how people always question why you want to do what you want to do. If everyone explained their full use case in these questions, no one would be able to read them, much less answer them.
B T - I really hate asking any questions online for this reason. If you want to help, that's great, but don't play 20 questions and force them justify themselves.
Disagree with B T and Mason240 here: it's often valuable to show the questioner another solution that they haven't thought of. Flagging up code smells is a useful service. It's a long way from 'I'm curious as to why...' to 'force them to justify themselves'.
There are lots of things you can't do with longs eg index an array.

N
Neuron

A new method has been added with Java 8 to do just that.

import static java.lang.Math.toIntExact;

long foo = 10L;
int bar = toIntExact(foo);

Will throw an ArithmeticException in case of overflow.

See: Math.toIntExact(long)

Several other overflow safe methods have been added to Java 8. They end with exact.

Examples:

Math.incrementExact(long)

Math.subtractExact(long, long)

Math.decrementExact(long)

Math.negateExact(long),

Math.subtractExact(int, int)


We also have addExact and multiplyExact. Of note is that division (MIN_VALUE/-1) and absolute value (abs(MIN_VALUE)) do not have safe convenience methods.
But what's a difference of using Math.toIntExact() instead of usual cast to int? The implementation of Math.toIntExact() just casts long to int.
@YamashiroRion Actually the implementation of toIntExact first checks whether the cast would lead to an overflow, in which case it throws an ArithmeticException. Only if the cast is safe it then performs cast from long to int which it returns. In other words, if you try to cast a long number that cannot be represented as int (eg any number strictly above 2 147 483 647) it will throw an ArithmeticException. If you do the same with a simple cast, your resulting int value will be wrong.
J
James McMahon

I think I'd do it as simply as:

public static int safeLongToInt(long l) {
    if (l < Integer.MIN_VALUE || l > Integer.MAX_VALUE) {
        throw new IllegalArgumentException
            (l + " cannot be cast to int without changing its value.");
    }
    return (int) l;
}

I think that expresses the intent more clearly than the repeated casting... but it's somewhat subjective.

Note of potential interest - in C# it would just be:

return checked ((int) l);

I'd always do the range check as (!(Integer.MIN_VALUE <= l && l <= Integer.MAX_VALUE)). I find it difficult to get my head around other ways of doing it. Pity Java does not have unless.
+1. This falls exactly under the "exceptions should be used for exceptional conditions" rule.
(In a modern general-purpose language it would be: "Eh? But ints have arbitrary size?")
@Tom: Personal preference, I guess - I prefer to have as few negatives as possible. If I'm looking at an "if" with a body which throws an exception, I'd like to see conditions that make it look exceptional - like the value being "off the bottom end" of int.
@Tom: In that case I'd remove the negative, put the cast/return inside the "if" body, and then throw an exception afterwards, if you see what I mean.
H
Henrik Aasted Sørensen

With Google Guava's Ints class, your method can be changed to:

public static int safeLongToInt(long l) {
    return Ints.checkedCast(l);
}

From the linked docs:

checkedCast public static int checkedCast(long value) Returns the int value that is equal to value, if possible. Parameters: value - any value in the range of the int type Returns: the int value that equals value Throws: IllegalArgumentException - if value is greater than Integer.MAX_VALUE or less than Integer.MIN_VALUE

Incidentally, you don't need the safeLongToInt wrapper, unless you want to leave it in place for changing out the functionality without extensive refactoring of course.


Guava's Ints.checkedCast does exactly what OP does, incidentally
+1 for Guava solution, though no real need to wrap it in another method, just call Ints.checkedCast(l) directly.
Guava also has Ints.saturatedCast which will return the nearest value instead of throwing an exception.
Yes, it's safe to use existing api as my case, the library already in the project: to throw exception if invalid: Ints.checkedCast(long) and Ints.saturatedCast(long) to get the nearest for converting long to int.
J
Jaime Saiz

With BigDecimal:

long aLong = ...;
int anInt = new BigDecimal(aLong).intValueExact(); // throws ArithmeticException
                                                   // if outside bounds

I like this one, anyone has something against this solution?
Well, it's allocating and throwing away a BigDecimal just to get at what should be a utility method, so yeah, that's not the best process.
@Riking in that regard, it’s better to use BigDecimal.valueOf(aLong), instead of new BigDecimal(aLong), to denote that a new instance is not required. Whether the execution environment does caching at that method, is implementation specific, just like the possible presence of Escape Analysis. In most real life cases, this has no impact on the performance.
E
Eric Woodward

here is a solution, in case you don't care about value in case it is bigger then needed ;)

public static int safeLongToInt(long l) {
    return (int) Math.max(Math.min(Integer.MAX_VALUE, l), Integer.MIN_VALUE);
}

seems, you are wrong ... it will be working nice then negative. also, what does mean too low ? please, provide use-case.
this solution is the fast one and safe one, then we are talking to cast Long to Int to obey result.
A
Andreas

DONT: This is not a solution!

My first approach was:

public int longToInt(long theLongOne) {
  return Long.valueOf(theLongOne).intValue();
}

But that merely just casts the long to an int, potentially creating new Long instances or retrieving them from the Long pool.

The drawbacks

Long.valueOf creates a new Long instance if the number is not within Long's pool range [-128, 127]. The intValue implementation does nothing more than: return (int)value;

So this can be considered even worse than just casting the long to int.


Your attempt to help is appreciated, but giving an example of something that doesn't work isn't quite the same as providing a solution that does work. If you would edit to add a correct way, this could be pretty good; otherwise, it's not really suitable to be posted as an answer.
Okay, why not having both DOs and DONTs? Tbh, sometimes I wish I had a list of how to not do things (DONTs) to check whether I used such a pattern/code. Anyway, I can delete this "answer".
Good anti-pattern. Anyway it would have been great if you explained what happens if the long value is out-of-range for int? I guess there will be a ClassCastException or something like this?
@PeterWippermann: I have added some more info. Do you consider them understandable resp. explanatory enough?
T
Tom Hawtin - tackline

I claim that the obvious way to see whether casting a value changed the value would be to cast and check the result. I would, however, remove the unnecessary cast when comparing. I'm also not too keen on one letter variable names (exception x and y, but not when they mean row and column (sometimes respectively)).

public static int intValue(long value) {
    int valueInt = (int)value;
    if (valueInt != value) {
        throw new IllegalArgumentException(
            "The long value "+value+" is not within range of the int type"
        );
    }
    return valueInt;
}

However, really I would want to avoid this conversion if at all possible. Obviously sometimes it's not possible, but in those cases IllegalArgumentException is almost certainly the wrong exception to be throwing as far as client code is concerned.


This is what recent versions of Google Guava Ints::checkedCast do.
m
mob

Java integer types are represented as signed. With an input between 231 and 232 (or -231 and -232) the cast would succeed but your test would fail.

What to check for is whether all of the high bits of the long are all the same:

public static final long LONG_HIGH_BITS = 0xFFFFFFFF80000000L;
public static int safeLongToInt(long l) {
    if ((l & LONG_HIGH_BITS) == 0 || (l & LONG_HIGH_BITS) == LONG_HIGH_BITS) {
        return (int) l;
    } else {
        throw new IllegalArgumentException("...");
    }
}

I don't see what signedness has to do with it. Could you give an example which doesn't lose information but does fail the test? 2^31 would be cast to Integer.MIN_VALUE (i.e. -2^31) so information has been lost.
@Jon Skeet: Maybe me and the OP are talking past each other. (int) 0xFFFFFFFF and (long) 0xFFFFFFFFL have different values, but they both contain the same "information", and it is almost trivial to extract the original long value from the int.
How can you extract the original long value from the int, when the long could have been -1 to start with, instead of 0xFFFFFFFF?
Sorry if I"m not clear. I'm saying that if the long and the int both contain the same 32 bits of information, and if the 32nd bit is set, then the int value is different from the long value, but that it is easy to get the long value.
@mob what is this in reference to? OP's code correctly reports that long values > 2^{31} cannot be casted to ints
M
Maury
(int) (longType + 0)

but Long can not exceed the maximum :)


The + 0 adds nothing to this conversion, it might work if Java treated numeric type concatenation in a similar way to strings, but since it doesn't your doing an add operation for no reason.
R
Rajat Anantharam

One other solution can be:

public int longToInt(Long longVariable)
{
    try { 
            return Integer.valueOf(longVariable.toString()); 
        } catch(IllegalArgumentException e) { 
               Log.e(e.printstackstrace()); 
        }
}

I have tried this for cases where the client is doing a POST and the server DB understands only Integers while the client has a Long.


You will get a NumberFormatException on "real long" values: Integer.valueOf(Long.MAX_VALUE.toString()); results in java.lang.NumberFormatException: For input string: "9223372036854775807" that pretty much obfuscates the Out-Of-Range-Exception because it is now treated in the same way a string containing letters is treated.
It also doesn't compile because you don't always return a value.