Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

Java Top

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

> CHECK OUT THE COURSE

1. Overview

Java stores Integer using 32 bits of memory. Thus, Integer‘s(or int‘s) range is from -231 (-2,147,483,648) to 231-1 (2,147,483,647)Therefore, when we see an error message like “java: integer number too large …“, we can usually easily find the problem and fix it.

However, in some cases, when we see this error message, we might not understand why the error occurred. And it'll take some time to fix the problem.

So, in this tutorial, we'll take a closer look at a couple of pitfalls that lead to this error and address the reason behind the error.

2. Integer Literals Pitfall #1

The Java compiler complains when we assign a literal number out of the mentioned integer range to an int variable. For example, let's say we compile this assignment:

int a = 12345678912345;

The compiler reports this error:

java: integer number too large

We can quickly find the problem by reading the error message. We may think int is not the right type for such a big number, so we change the type to long:

long a = 12345678912345;

However, when we recompile the code, we get the same compilation error: “integer number too large“. We'll wonder why the compiler still complains about integer, although we declared the variable as long? Next, we may spend some time double-checking if we saved the file correctly or restarting the IDE, and so on. However, the problem still stays.

When we write number literals in Java, no matter whether it's within or outside the integer range, Java treats it as the Integer/int type. If we want an integer literal to be long, we must add the ‘L‘ or ‘l‘ suffix. This is also explicitly stated in the Java Language Specification:

An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int

Therefore, to fix the problem, we should add an ‘L‘ after the literal number:

long a = 12345678912345L;

It's worth mentioning when we use decimal literals without any suffix, Java treats them as double. In case we want them to be float, we must add an ‘F‘ or ‘f‘ suffix:

float a = 1024.42; // compiler error -  java: incompatible types: possible lossy conversion from double to float
float a = 1024.42F; // compiled

3. Integer Literals Pitfall #2

Now we understand that we should add the ‘L‘ suffix to integer literals for the long type. Next, let's see another example:

long a = 007L;

As the code above shows, we have the suffix ‘L‘ this time, and a‘s type is long. The code compiles smoothly even if there are leading zeros. If we check a's value, the variable a holds 7, as expected. So, we may think Java is so intelligent that it ignores the leading zeros of numbers.

Now, let's declare another variable:

long b = 008L;

Again, the compiler reports “integer number too large” if we compile the code.

This time, there's no sign of an integer in our code. Furthermore, long a = 007L; has worked without any problem. Why does long b = 008L fail? It may take some time to solve the problem.

Actually, we've fallen into another integer literals pitfall. This is because, in Java, an integer literal can also be expressed in octal (base 8). Further, an octal integer consists of a leading zero followed by one or more of the digits 0 through 7.

Therefore, everything's fine when we assign ‘007L‘ to a variable. This is because Java reads the octal integer literal ‘007′, and treats it as long. However, when we assign ‘008L‘ to a variable, 008 is not a valid octal integer. Thus, the compiler reports that error.

After we understand the cause of the problem, the fix is pretty simple – removing the leading zeros:

long b = 8L;

4. Conclusion

In this article, we've discussed two common pitfalls when we work with integer literals in Java.

Understanding the reason behind the compilation error may help us find and fix the problem quickly.

Java bottom

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

>> CHECK OUT THE COURSE
Generic footer banner
Comments are closed on this article!