Primitive types

Figure 62. Java types

Figure 63. Java signed integer primitive types

Name	Bytes	Type	Range	Literal samples
`byte`	1 / 8 bit	Signed integer	$[- 2^{7}, 2^{7} - 1]$	-
`short`	2 / 16 bit	Signed integer	$[- 2^{15}, 2^{15} - 1]$	-
`int`	4 / 32 bit	Signed integer	$[- 2^{31}, 2^{31} - 1]$	0, 1, +1, -42, 0b1101, 017, 0xC
`long`	8 / 64 bit	Signed integer	$[- 2^{63}, 2^{63} - 1]$	0L, 1L, +1L, -42L, 0b1101L, 017L, 0xCL

Figure 64. int literals explained

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 65. Java unsigned integer, floating point and boolean primitive types

Name	Bytes	Type	Range	Literal samples
`char`	2 / 16 bit	Unsigned integer	$[0, 2^{16} - 1]$	'A', '*', '-', 'Ç', '⇶' ...
`float`	4	Floating point	$\pm 1.18 \times 10^{- 38}$ to $\pm 3.4 \times 10^{38}$	3.14f, 0.022f, -3.4E-24f
`double`	8	Floating point	$\pm 2.23 \times 10^{- 308}$ to $\pm 1.8 \times 10^{308}$	3.14, 0.022, -3.4E-24, 3.14d,...
`boolean`	?	Logical value	not applicable	`true`, `false`

exercise No. 6

Literal samples

Create code printing an example for each type of literal in Java.

Tip

You may follow Java Literals.

System.out.println("Java is awesome!"); // String
System.out.println(123);                // int
System.out.println(2342475545345345L);  // long
System.out.println(3.1415926F);         // float
System.out.println(3.1415926);          // double
System.out.println(true);               // boolean
System.out.println('A');                // char

exercise No. 7

Literals of type int

int literals (and likewise long) can be expressed in 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}

Calculate the above sample values in decimal beforehand. Then write and execute code printing the above values.

Manual calculation:

0B11011 = 16 + 8 + 0 + 2 + 1 = 27
037 = 3 * 8 + 7 = 31
123 = 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

Execute the following code:

System.out.println(3123424234);

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

Tip

From now on we will usually omit related boilerplate code. The above line actually refers to the execution of:
```
package ...;
public class X {
  public static void main(String[] args) {

    System.out.println(3123424234);

  }
}
```

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

In Java™ 3123424234 is a literal of type int ranging from $- 2^{31}$ to $2^{31} - 1$ or -2147483648 to 2147483647, inclusive. A value of 3123424234 exceeds the upper bound thus requiring a literal of 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 and dig into its byte level representation.

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 failure.

Execution yields a surprising value of -2. This is due to an overflow error: 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 is the four-byte 2-complement representation of -2.

It actually is a sign bit interference: Lets pretend we were having just a 31 bit unsigned representation rather than 32 bit two complement. The very same sum would then simply yield 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$ as well.

But in 32 bit 2-complement representation the leftmost bit represents the sign. It gets overwritten by the arithmetic overflow yielding an even negative result.

exercise No. 10

Correcting the error

How do we correct the erroneous outcome in Strange sum result ?

Tip

Consider related Java™ literals.

Prev	Up	Next
Integer, ASCII and Unicode	Home	Variables