Definition
The answer is no, it does not compile. Here is why:
- Leading 0 = octal. In Java, an integer literal starting with
0is interpreted as base 8 (octal). - Octal digits are 0-7. The digit 9 does not exist in octal.
- Compiler error.
int i = 09;fails with "integer number too large" or "invalid digit" error. - Fix: Write
int i = 9;(no leading zero) for decimal nine.
A bank form where any amount starting with 0 is read in a special base-8 code. Writing 09 is like using a digit that does not exist in the code – the form is rejected before processing.
Understanding the Concepts
What are the integer literal prefixes in Java?
| Prefix | Base | Valid digits | Example | Decimal value |
|---|---|---|---|---|
| None | 10 (decimal) | 0-9 | 42 | 42 |
| 0 | 8 (octal) | 0-7 | 052 | 42 |
| 0x or 0X | 16 (hex) | 0-9, A-F | 0x2A | 42 |
| 0b or 0B | 2 (binary) | 0-1 | 0b101010 | 42 |
int decimal = 42; // base 10
int octal = 052; // base 8: 5*8 + 2 = 42
int hex = 0x2A; // base 16: 2*16 + 10 = 42
int binary = 0b101010; // base 2: 32+8+2 = 42
System.out.println(decimal + " " + octal + " " + hex + " " + binary);
// Output: 42 42 42 42
Why does 09 not compile?
Because 09 starts with 0, the compiler reads it as octal. Octal only allows digits 0 through 7. The digit 9 is invalid.
// int i = 09; // COMPILE ERROR: integer number too large (invalid octal digit)
// int j = 08; // COMPILE ERROR: same reason – 8 is not an octal digit
int k = 07; // OK: octal 7 = decimal 7
int m = 010; // OK: octal 10 = 1*8 + 0 = decimal 8 (NOT 10!)
What is the sneaky 010 bug?
This is the real danger. 010 compiles without any error but equals 8, not 10.
int a = 10; // decimal ten
int b = 010; // octal: 1*8 + 0 = EIGHT
System.out.println(a); // 10
System.out.println(b); // 8 (surprise!)
System.out.println(a == b); // false!
This bug happens when developers pad numbers with leading zeros for visual alignment:
// BUG: months 08 and 09 don't compile, months 01-07 are wrong values
// int[] months = {01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12};
// 1 2 3 4 5 6 7 ERR ERR 10 11 12
// CORRECT: no leading zeros
int[] months = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12};
Why do account numbers and cheque numbers use String, not int?
In banking, many identifiers have significant leading zeros: account number 00123456, cheque number 000789, IFSC code SBIN0001234.
An int cannot preserve leading zeros because it stores the numeric value, not the text. int x = 00123456; either fails as invalid octal or silently gives a wrong value.
// WRONG: leading zeros lost or misinterpreted
// int accountNum = 00123456; // octal interpretation → wrong value
// CORRECT: store as String to preserve leading zeros
String accountNum = "00123456";
String chequeNum = "000789";
String ifsc = "SBIN0001234";
Rule: if leading zeros are meaningful, use String, not a numeric type.
What about parseInt and leading zeros?
Integer.parseInt() always parses as decimal (base 10) by default. Leading zeros in the string are ignored.
int a = Integer.parseInt("09"); // 9 (decimal, no octal interpretation)
int b = Integer.parseInt("010"); // 10 (decimal, NOT octal 8)
This is different from source code literals where leading zeros mean octal. parseInt does not use the literal rules.
What are common mistakes?
- Padding with leading zeros for alignment.
07, 08, 09– 07 compiles as octal 7, 08 and 09 fail. 01-07 compile but give octal values, which differ from decimal for 010+. - Storing zero-padded IDs as int. Account numbers, cheque numbers, and PINs with leading zeros must be String.
- Assuming 010 == 10. It equals 8. This is a silent, hard-to-find bug.
- Confusing source literal rules with parseInt rules.
parseInt("010")is decimal 10.int x = 010;is octal 8.
What should a senior engineer know?
- Octal is inherited from C. Java kept the leading-zero convention for compatibility. Most modern languages have moved away from it.
- Kotlin dropped octal literals. In Kotlin,
010is decimal 10, not octal 8. This eliminates the entire class of bugs. - Underscores for readability.
int million = 1_000_000;is valid since Java 7. Underscores do not change the base. - JSON does not allow leading zeros.
{"amount": 09}is invalid JSON. Parsers reject it.
Visual Overview
Integer literal prefixes:
42 → decimal (base 10) = 42
052 → octal (base 8) = 42
0x2A → hex (base 16) = 42
0b101010 → binary (base 2) = 42
The 09 trap:
09 → leading 0 → octal → 9 is invalid → COMPILE ERROR
08 → leading 0 → octal → 8 is invalid → COMPILE ERROR
07 → leading 0 → octal → 7 is valid → decimal 7
010 → leading 0 → octal → 1*8+0 → decimal 8 (NOT 10!)
parseInt vs literal:
parseInt("010") → always decimal → 10
int x = 010; → octal literal → 8
Key Takeaway
No, int i = 09 does not compile. A leading zero in a Java integer literal makes it octal (base 8), and octal only allows digits 0 through 7. The digit 9 does not exist in octal, so the compiler rejects it.
The sneakier bug is 010, which compiles without error but equals 8, not 10, because octal 10 is 1 times 8 plus 0. This catches developers who pad numbers with leading zeros for visual alignment.
In banking, identifiers like account numbers, cheque numbers, and IFSC codes often have significant leading zeros. These must be stored as String, not int, because an int cannot preserve leading zeros. And Integer.parseInt("010") is always decimal 10, unlike the source literal 010 which is octal 8.
One sentence to remember: a leading zero in a Java literal means octal, so 09 is invalid, 010 is 8 not 10, and zero-padded identifiers must be stored as String.
---