Primitive types

Figure 64. Java types

Figure 65. Java signed integer primitive types

Name	Bytes	Type	Range	Literal samples
`byte`	1	Signed integer	$[- 2^{7}, 2^{7} - 1]$	No `byte` literal in Java™
`short`	2	Signed integer	$[- 2^{15}, 2^{15} - 1]$	No `short` literal in Java™
`int`	4	Signed integer	$[- 2^{31}, 2^{31} - 1]$	0, 1, +1, -42: Decimal representation 0x2C: Hexadecimal representation 017: Octal representation 0b1101: Binary representation
`long`	8	Signed integer	$[- 2^{63}, 2^{63} - 1]$	0L, 1L, +1L, -42L: Decimal representation ... (see above + “L”)

Figure 66. Four int literal representations of decimal 29

Literal	Discriminator	Type	Value
29	base 10	Decimal	$2 \times 10^{1} + 9 \times 10^{0}$
0b11101	0b, base 2	Binary	$1 \times 2^{4} + 1 \times 2^{3} + 1 \times 2^{2}$ $+ 0 \times 2^{1} + 1 \times 2^{0}$
0x1D	0x, base 16	Hexadecimal	$1 \times 16^{1} + 13 \times 16^{0}$
035	0, base 8	Octal	$3 \times 8^{1} + 5 \times 8^{0}$

Figure 67. Java unsigned integer, floating point and boolean primitive types

Name	Bytes	Type	Range	Literal representation samples
`char`	2	Unsigned integer	$[0, 2^{16} - 1]$	'A', '*', 'ê', '⇶': Single quotes '\u21e8': Unicode / hexadecimal
`float`	4	Floating point	$\pm 1.18 \times 10^{- 38}$ to $\pm 3.4 \times 10^{38}$	3.14f, 0.022F -3.4E-24f: Exponential $-3.4 \times 10^{- 24}$
`double`	8	Floating point	$\pm 2.23 \times 10^{- 308}$ to $\pm 1.8 \times 10^{308}$	2.718d, 0.12323D 2.74E12D: Exponential $2.74 \times 10^{12}$
`boolean`	?	Logical value	not applicable	`true`, `false`

exercise No. 6

Literal samples

Create code printing an example for each type of literal in all its different representations.

Literal type	Representations
Signed integer: int long	Hexadecimal (e.g. `5C`) Decimal (e.g. `234`) Octal (e.g. `027`) Binary (e.g. `0B11011`)
Unsigned integer: char	Pair of single quotes (e.g. `'⇨'`) Unicode (e.g. `'\u21E8'`)
Floating types: float double	Decimal style (e.g. `-0.03422334`) Scientific notation (e.g. `-3.422334E-2` aka $-3.422334 \times 10^{- 2}$ )
Logical type: boolean	`true` / `false`
String type: String	Single line: `"Java is awesome!"` Multi line: `""" This is the end my friend!"""`

Assign each literal sample to a variable of corresponding type. Your code may read:

// Signed integer

int     intHexadecimal = ...,  // No. 1
        intDecimal = ...,      // No. 2
        ...
                      ...;
long ...                   
        ...      
                       ...;    // No. 17

Due to the above table's combinations your code will have 2 x 4 + 1 x 2 + 2 x 2 + 1 x 1 + 1 x 2 = 17 variable declarations.

Tip

General remark: From now on we will usually omit related boilerplate code. The above code actually refers to:

package ...;
public class X {
  public static void main(String[] args) {

    // Signed integer

    int     intHexadecimal = ...,  // No. 1
    intDecimal = ...,              // No. 2
                  ...;
    long ...                   
           ...      
                           ...;    // No. 17
  }
}

You may follow Java Literals.
Some primitive types don't have corresponding literals.

// Signed integer

int     intHexadecimal = 0X5c,
        intDecimal = 234,
        intOctal = 037,
        intBinary = 0B11011;

long    longHexadecimal = 0X5cL,
        longDecimal = 234L,
        longOctal = 037L,
        longBinary = 0B11011L;

// Unsigned integer

char      charQuote = '⇨',
        charUnicode = '\u21e8';

// Floating point

float       floatDecimal = -0.03422334F,
        floatExponential = -3.422334E-2F;

double       doubleDecimal = -0.03422334D,
        doubleExponential = -3.422334E-2D;

// Logical

boolean bool = true;

// Strings

String       stringLine = "Java is awesome!",
        stringMultiLine = """
                      This is
                      the end
                      my friend!""";

exercise No. 7

Literals of type int

Both int and long literals can be expressed by four different representations. We provide related samples:

Representation	Base	Sample	Digits
Binary	2	`0B11011`	{0, 1}
Octal	8	`037`	{0, 1, ..., 7}
Decimal	10	`123`	{0, 1, ..., 9}
Hexadecimal	16	`0X2F`	{0, 1,...,9, A, B, C, D, E, F}

Manually turn the above non-decimal sample values into decimal representation beforehand.
Then write and execute code printing these values.
Compare your manually computed values against the actual results.

Manual calculation:

0B11011 = 1 * 16 + 1 * 8 + 0 * 4 + 1 * 2 + 1 =  27 
    037 =                          3 * 8 + 7 =  31
    123 =               1 * 100 + 2 * 10 + 3 = 123
   0X2F =           2 * 16 + F = 2 * 16 + 15 =  47

Code execution:

Code	Result
System.out.println(0B11011); // Binary System.out.println(037); // Octal System.out.println(123); // Decimal System.out.println(0X2F); // Hexadecimal	27 31 123 47

exercise No. 8

Integer overflow

Try executing:

System.out.println(3123424234);

Whats wrong here? How can we achieve the desired output?

Tip

Consider int and long types and their corresponding literals.

The code snippet fails with an »Integer number too large« error.

In Java™ 3123424234 claims to be a literal of type int. Unfortunately four byte int values only range from $- 2^{31}$ to $2^{31} - 1$ or -2147483648 to 2147483647 inclusive. A value of 3123424234 exceeds the upper bound thus failing to be an int literal. We therefore require a literal of larger eight byte type long being indicated by an »l« or »L« suffix:

System.out.println(3123424234L);

exercise No. 9

Strange sum result

Execute the following code:

System.out.println(2147483647 + 2147483647);

Explain the result.

Tip

Consider the 2147483647 literal's data type, range of values and dig into its byte level representation.
Find a way correcting the underlying flaw.

Tip

Consider the long type.

Execution yields a surprising value of -2 instead of the expected 4294967294.

2147483647 or $2^{31} - 1$ is the largest possible int value being allowed in four byte (=32 bit) two complement representation. It is thus perfectly clear that adding this value to itself will result in an arithmetic overflow failure.

Java™ uses the aforementioned four byte two-complement representation for int values. At binary level our sum thus reads:
```
  01111111_11111111_11111111_11111111
+ 01111111_11111111_11111111_11111111
_____________________________________
  11111111_11111111_11111111_11111110
```
This appears to be correct. But in fact due to two-complement representation the leftmost bit represents the sign. The addition toggles this sign bit from positive to negative which actually is an overflow: We end up with the four-byte 2-complement representation of -2.

Lets pretend we were having just a 31 bit unsigned representation rather than 32 bit two complement. The very same sum would then clearly show an overflow:
```
  1111111_11111111_11111111_11111111
+ 1111111_11111111_11111111_11111111
_____________________________________
 11111111_11111111_11111111_11111110
```
In 31 bit representation the leftmost »red« bit would be discarded leaving us with an incorrect value of 2147483646 or $2^{31} - 2$ rather than the correct value of $2^{32}$ as well.

Correcting this error is easily achieved by using an addition of long rather than int values:

Code	System.out.println(2147483647L + 2147483647);
Result	4294967294

Remark: You may wonder why we just need one “L” for the left summand rather than both: When changing just one int summand into a long the addition will already be processed as “long + long = long” .

Prev	Up	Next
Integer, ASCII and Unicode	Home	Variables