Java L Specification (Long)

Question

It looks like when you enter a number in Java, the compiler automatically reads it as an integer, so when you enter (long) 6000000000 (not in the integer range), it will complain that 6000000000 is not an integer, To fix this, I had to specify 6,000,000,000l. I just found out about this specification.

Are there other number specifications, such as short, byte, float, double? It seems like this would be good, because (I suppose), if you could indicate the number you enter is short, then java should not throw it - this is an assumption, correct me if I am wrong, I would usually I searched for this question myself, but I don’t know what this number specification is called.

Answer 1

There are special suffixes for long (for example, 39832L ), float (for example, 2.4f ) and double (for example, -7.832d ).

If there is no suffix and it is an integral type (for example, 5623 ), it is considered int . If it is not an integral type (for example, 3.14159 ), it is considered double .

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

The Java specification allows for both upper and lower case suffix, but the upper case variant for long is preferred, since upper case L less easily confused with number 1 than lower case L

See section

Answer 2

I hope you don’t mind the small tangent, but I thought you might be interested to know that besides F (for float), D (for double) and L (for long), a proposal was made to add suffixes for byte and short - Y and S respectively. This eliminates the need for bytes when using literal syntax for byte (or short) arrays. Quoting an example from a sentence:

KEY BENEFITS: Why is the platform better if the offer is accepted?

rough code like

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

can be transcoded as

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

Joe Darcy controls the project coin for Java 7, and his blog is an easy way to keep track of these offers.

Answer 3

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

Answer 4

By default, any integral primitive data type (byte, short, int, long) will be treated as an int type by a java compiler. For bytes and short, if the value assigned to them is in their range, there are no problems and no suffixes are required. If the value assigned to the byte and the short value exceeds their range, explicit tick casting is required.

Example:

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

to overcome this fulfillment.

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

In the case of a long data type, it can take an integer value without any problems. Suppose we denote by

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

in this case, an L / l type suffix is ​​not required. By default, the value 2147483647 is considered by the java compiler of type int. The casting of the internal type is done by the compiler, and the int is automatically raised to type Long.

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

Here we need to put the suffix as L to handle the literal 2147483648 as a long type using the java compiler.

so finally

 Long l = 2147483648L;// works fine. 

Answer 5

It seems that this would be good for because (I assume) if you could indicate the number you enter is short, then java would not have to drop it

Since literal parsing occurs at compile time, this is completely out of place in terms of performance. The only reason for short and byte suffixes is that this leads to more compact code.

Answer 6

Consider:

 long l = -1 >>> 1; 

against

 int a = -1; long l = a >>> 1; 

Now you expect the application code fragments to have the same value for the variable l . Therefore, we need an expression on int literals, which should be executed as int s.