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

User · Answer

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.

User · Answer

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

User · Answer

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

User · Answer

To understand why it is necessary to distinguish between int and long literals  consider   long l   -1  gt  gt  gt  1    versus  int a   -1  long l   a  gt  gt  gt  1    Now as you would rightly expect  both code fragments give the same value to variable l  Without being able to distinguish int and long literals  what is the interpretation of -1  gt  gt  gt  1   -1L  gt  gt  gt  1        or   int -1  gt  gt  gt  1        So even if the number is in the common range  we need to specify type  If the default changed with magnitude of the literal  then there would be a weird change in the interpretations of expressions just from changing the digits   This does not occur for byte  short and char because they are always promoted before performing arithmetic and bitwise operations  Arguably their should be integer type suffixes for use in  say  array initialisation expressions  but there isn t  float uses suffix f and double d  Other literals have unambiguous types  with there being a special type for null

User · Answer

These are literals and are described in section 3 10 of the Java language spec

User · Answer

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 mdash 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

[java] Java's L number (long) specification

Examples related to java

Examples related to numbers

Examples related to long-integer

Examples related to short

Examples related to specifications