Using downcasting in real app life

Question

I know that implicit casting is done automatically by the compiler and virtual machine, and that explicit casting is needed to convert types of data when Java is not sure if the result will be valid. Casting should be done between primitives or between objects.

My question is: If my application uses both integers as well as long integers - should I use long for both types? Or downcasting for long? Or casting for int?

Can usage of long for both types causes some problems?

You should make sure that your variable can accommodate all valid values. If a variable can contain values larger than the largest integer, it should be a long. — Vincent van der Weele, Jul 16 '13 at 12:26
@Thilo I think you in practice hardly ever encounter a 'lonely' long... either many values are large (in which case long is the only logical choice), or none at all. So no, not just long for everything, only long when it makes sense :) — Vincent van der Weele, Jul 16 '13 at 12:34
@Thilo `long` is common to represent currency (given precision issues with `float`), it's also common to represent a timestamp, and also for auto-incrementing IDs. Point being: there are specific use cases for which a 64 bit integer is necessary, and 9/10 of these are things that - given the proper forethought - you will be able to recognize during your design phase. — Colin M, Jul 16 '13 at 12:37

score 3 · Accepted Answer · edited May 23 '17 at 11:56

3

I will probably go with the right datatype for right operations , long if I need long , int if int is enough for my requirements . Common sense would be to think using long for int probably will slow you down in general, but again this depends on the specific JVM implementation. You will have to decide based on the range which you want to target .

Again , if there are lots of casting involved in your program , then better to go for a datatype like long which can accommodate a larger range than int and save you from casts and loss of data in that process . Having said that , long might be slower than intalthough in modern processors and JVMs I doubt that might affect much .

May be , enlightened ones here can answer this question better.

You can also read some nice SO Q&A here and here.

edited May 23 '17 at 11:56

Community

1
1

answered Jul 16 '13 at 12:28

AllTooSir

48,828
16
130
164

2

It will also, of course, take more memory to use `long` everywhere – Colin M Jul 16 '13 at 12:28
I don't think long is slower than int, although as you said this depends on the JVM implementation for the underlying architecture. Most likely 64-bit JVMs will have no speed issues when using long (and maybe even it's faster than using int since it's the native word length) – m0skit0 Jul 16 '13 at 12:33

m0skit0 · Answer 2 · 2013-07-16T12:40:39.797

3

I think you should use a data type that covers all your values, so I would use long for everything, because it simplifies the code and avoids potentially risky conversions.

Casting from long to int can make you lose data since a long is bigger than an int (thus data is truncated in the cast).
Casting from int to long is almost (see Colin Morelli's comment about this below) the same as using long from the beginning and you avoid juggling with 2 types . Also this casting just doesn't make sense as you're taking up memory for nothing actually (unless you were using an int and a method explicitly requires a long as parameter, then you obviously have no choice but cast).

The downsides I see using long are:

long doubles the memory needed instead of int (still take into account Colin Morelli's comment below).
long might yield slower performance (as said above, but I'm not sure about this)

edited Jul 16 '13 at 12:40

answered Jul 16 '13 at 12:28

m0skit0

25,268
11
79
127

4

Casting from `int` to `long` is not the same as using `long` from the beginning, actually. Since primitives are passed by value, you could pass an `int` 5 levels deep and _then_ do a `long` conversion, leaving you with 5 `int`s and 1 `long`, versus having 6 `long`s. In that particular scenario, the difference is minimal, but it could result in a potentially large memory difference – Colin M Jul 16 '13 at 12:33
@ColinMorelli absolutely, I didn't take that into account. – m0skit0 Jul 16 '13 at 12:40

score 0 · Answer 3 · answered Jul 16 '13 at 12:35

0

It Depends on your date range. Take a look at The Java Tutorials: Primitive Data types if you know that your numbers will be between Integer.MIN_VALUE and Integer.MAX_VALUE don't sweet, casting will work as expected. Else, go for long or BigInteger.

answered Jul 16 '13 at 12:35

Anthony Accioly

21,918
9
70
118

What happens if only some data cannot fit into int? Say 1% is long, 99% is int. – m0skit0 Jul 16 '13 at 12:50
This is a business decision. You either throw errors for the 1% or pay the overheads to accommodate the corner cases, it depends on how relevant the 1% really is. – Anthony Accioly Jul 16 '13 at 13:17
Business decision? Since when does business understands what a long is? – m0skit0 Jul 16 '13 at 13:54
They do understand how relevant those 1% of really big numbers really are. – Anthony Accioly Jul 16 '13 at 14:03
Relevant? I don't understand what you mean. You have to process **all** (100%) the data, not discard that 1% (this is the OP question btw...). – m0skit0 Jul 16 '13 at 14:09

score 0 · Answer 4 · answered Jul 16 '13 at 12:44

0

You really need to be more clear on the range of numbers you are dealing with. Well with the given input the best bet would be to go with long. But If you really need to make it generic and memory is not a constraint then you could use BigInteger.

answered Jul 16 '13 at 12:44

blganesh101

3,647
1
24
44

Using downcasting in real app life

4 Answers4