Java's L number (long) specification

Question

It appears that when you type in a number in Java, the compiler automatically reads it as an integer, which is why when you type in (long) 6000000000 (not in integer's range) it will complain that 6000000000 is not an integer. To correct this, I had to specify 6000000000L. I just learned about this specification.

Are there other number specifications like for short, byte, float, double? It seems like these would be good to have because (I assume) if you could specify the number you're typing in is a short then java wouldn't have to cast it - that is an assumption, correct me if I'm wrong. I would normally search this question myself, but I don't know what this kind of number specification is even called.

Solution 1

There are specific suffixes for long (e.g. 39832L), float (e.g. 2.4f) and double (e.g. -7.832d).

If there is no suffix, and it is an integral type (e.g. 5623), it is assumed to be an int. If it is not an integral type (e.g. 3.14159), it is assumed to be a double.

In all other cases (byte, short, char), you need the cast as there is no specific suffix.

The Java spec allows both upper and lower case suffixes, but the upper case version for longs is preferred, as the upper case L is less easy to confuse with a numeral 1 than the lower case l.

See the JLS section 3.10 for the gory details (see the definition of IntegerTypeSuffix).

Solution 2

By default any integral primitive data type (byte, short, int, long) will be treated as int type by java compiler. For byte and short, as long as value assigned to them is in their range, there is no problem and no suffix required. If value assigned to byte and short exceeds their range, explicit type casting is required.

Ex:

byte b = 130; // CE: range is exceeding.

to overcome this perform type casting.

byte b = (byte)130; //valid, but chances of losing data is there.

In case of long data type, it can accept the integer value without any hassle. Suppose we assign like

long l = 2147483647; //which is max value of int

in this case no suffix like L/l is required. By default value 2147483647 is considered by java compiler is int type. Internal type casting is done by compiler and int is auto promoted to Long type.

long l = 2147483648; //CE: value is treated as int but out of range 

Here we need to put suffix as L to treat the literal 2147483648 as long type by java compiler.

so finally

long l = 2147483648L;// works fine.

Solution 3

I hope you won't mind a slight tangent, but thought you may be interested to know that besides F (for float), D (for double), and L (for long), a proposal has been made to add suffixes for byte and short—Y and S respectively. This would eliminate to the need to cast to bytes when using literal syntax for byte (or short) arrays. Quoting the example from the proposal:

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

cruddy code like

 byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};

can be recoded as

 byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };

Joe Darcy is overseeing Project Coin for Java 7, and his blog has been an easy way to track these proposals.

Solution 4

These are literals and are described in section 3.10 of the Java language spec.

Solution 5

It seems like these would be good to have because (I assume) if you could specify the number you're typing in is a short then java wouldn't have to cast it

Since the parsing of literals happens at compile time, this is absolutely irrelevant in regard to performance. The only reason having short and byte suffixes would be nice is that it lead to more compact code.

View more solutions

Comments

[jbu]

that would be nice...I've always found that all the casts are really annoying

[davidcesarino]

Late entry: removing potential sources of ambiguity is always good, and I don't disagree... but I believe if you find yourself confusing 1 with l and 0 with O (and so on), your priority is to set the font right (if you can), then worry about making sure you don't miss the Shift key.

[luigi7up]

@SimonNickerson I have a question about suffixes... If I declare a long or a double variable like: long _lo = 30; and not 30L does this mean my variable will be converted into float ? Or in case of _lo = _lo + 2.77 that _lo will be casted into float although it was declared as long

[fmunshi]

No, floats are not involved here. In the first case, 30 is an int which gets automatically converted via a widening conversion to a long. In the second case, your statement is illegal. You'd have to explicitly cast the right hand side to long, e.g. _lo = (long) (_lo + 2.77)

[crush]

I take it this didn't make it into Java 7. Any word on if it will make it into a future update or Java 8?

[brady]

@crush I tried looking into it a few months back, and as far as I could tell, the proposal had been abandoned. We did get _ in numeric literals and the 0b prefix for binary literals though. Whoop.

[dingalapadum]

@DavidCesarino changing the font fixes the ambiguity for you - in that particular editor where you've set it right. Changing l to L fixes the ambiguity for everybody who might ever read your code including yourself when you are reading the code in a different Editor, IDE, looking at the source on the web (review tools, repositories, etc..). IMHO the priority is not to miss the Shift key. Btw. what font do you recommend? I like monospace and it's the default almost in all editors, CLIs etc that I've see and in this font l and 1 (0 and O resp.) are fairly similar.

[davidcesarino]

@dingalapadum As I said, you're right. Removing sources of ambiguity is definitely a right thing to do. I just said you should try not to use any editor where you could easily mistake them. In other words, the old suggestion of coding defensively, but not depending on it. About the font, it is very personal, but I always use Deja Vu Sans Mono whenever I can because 1) it is monospaced; 2) it doesn't have ambiguities between characters; and 3) I like its shapes, beautiful and graceful, almost like a good, readable sans-serif font (other good programming fonts feel too "metallic" IMHO).

[JoelBonetR]

I usually use Roboto mono on my IDEs, it makes it easy to read.

[JoelBonetR]

This proposals are probably implemented on kotlin instead of java, as oracle don't want the community tell them how to work... we're on 2018 and still nothing about this proposal, sadly

[The incredible Jan]

I would really be interested in what you meant back in the days. In both cases I get 2147483647 and I don't understand why I should expect something else.

[Brett]

@TheincredibleJan You would rightly expect Integer.MAX_VALUE, however if there was no way to distinguish between int and long literals it would be ambiguous. / I've no recollection of this question, but have clarified my answer anyway.

[Ali Al Amine]

it is confusing. why do we need to add L to cast it if it's already defined as Long. why doesn't the compiler treat the number as integer and cast it if L is added.