Definition
Three approaches:
- Scanner:
new Scanner(System.in)– easy methods:nextLine(),nextInt(),nextDouble(). Handles parsing. - BufferedReader:
new BufferedReader(new InputStreamReader(System.in))– faster, but returns only String (parse yourself). - Console:
System.console()– providesreadPassword()for hidden input. Returns null in IDEs.
Scanner is a helpful bank teller who reads your form and converts each field to the right type. BufferedReader is a fast scanner that reads the whole form as text and lets you parse it yourself. Console is the secure keypad that hides your PIN as you type.
Understanding the Concepts
Scanner
Scanner scanner = new Scanner(System.in);
System.out.print("Account ID: ");
String id = scanner.nextLine();
System.out.print("Amount: ");
BigDecimal amount = scanner.nextBigDecimal();
System.out.println("Transfer " + amount + " from " + id);
scanner.close();
BufferedReader
try (BufferedReader br = new BufferedReader(new InputStreamReader(System.in))) {
System.out.print("Account ID: ");
String id = br.readLine();
System.out.print("Amount: ");
BigDecimal amount = new BigDecimal(br.readLine());
System.out.println("Transfer " + amount + " from " + id);
}
Console (for passwords)
Console console = System.console();
if (console != null) {
char[] password = console.readPassword("Enter PIN: "); // hidden input
// process password
Arrays.fill(password, '\0'); // clear from memory
}
What should a senior engineer know?
- Scanner.nextInt() leaves a newline in the buffer. Call
scanner.nextLine()after to consume it. - System.console() returns null when running from an IDE. Use Scanner as fallback.
- In web applications, you never read System.in. Input comes from HTTP requests.
What are common mistakes?
A common mistake is not understanding the concept fully before using it in production banking applications.
Wrong approach:
package com.bank.service;
public class TransferService {
public void transfer(String fromAccount, String toAccount, double amount) {
// WRONG: using double for money
double balance = getBalance(fromAccount);
balance = balance - amount;
}
private double getBalance(String id) { return 10000.0; }
}
Correct approach:
package com.bank.service;
import java.math.BigDecimal;
public class TransferService {
public void transfer(String fromAccount, String toAccount, BigDecimal amount) {
// CORRECT: using BigDecimal for money
BigDecimal balance = getBalance(fromAccount);
balance = balance.subtract(amount);
}
private BigDecimal getBalance(String id) { return new BigDecimal("10000.00"); }
}
Always use BigDecimal for monetary calculations in banking systems to avoid floating-point precision errors.
What are the edge cases?
Edge cases can cause unexpected behavior in banking applications. Here are some to watch for.
package com.bank.edge;
public class EdgeCaseDemo {
public static void main(String[] args) {
// Edge case 1: null handling
String accountId = null;
try {
System.out.println(accountId.length());
} catch (NullPointerException e) {
System.out.println("Null account ID");
}
// Edge case 2: empty vs null
String emptyId = "";
System.out.println(emptyId.isEmpty()); // true
System.out.println(emptyId == null); // false
// Edge case 3: boundary values
java.math.BigDecimal zero = java.math.BigDecimal.ZERO;
java.math.BigDecimal negativeBalance = new java.math.BigDecimal("-0.01");
System.out.println(zero.compareTo(negativeBalance) > 0); // true
}
}
Null account ID
true
false
true
Always test with null values, empty strings, boundary values, and negative amounts in banking applications.
What are common interview follow-up questions?
Interviewers often follow up with these related questions:
- How does this concept apply to a high-throughput banking transaction system?
- What are the performance implications in a production environment?
- How would you debug issues related to this concept?
- What tools would you use to monitor this in production?
- How does this behave differently in Java 8 vs Java 17+?
When answering follow-up questions, always relate your answer back to practical experience. For example, at National Bank of India, Rajesh debugged a production issue related to this concept by using JFR recordings and heap dumps. Providing concrete examples from banking systems shows the interviewer that you understand both the theory and the practice.
Visual Overview
Scanner: easy, parses types, slower
BufferedReader: fast, returns String, parse yourself
Console: secure, readPassword(), null in IDEs
Web apps: no System.in – input from HTTP requests
Key Takeaway
Use Scanner for simple interactive input, BufferedReader for fast bulk reading, and Console for password input. Always close with try-with-resources. In production web applications, input comes from HTTP requests, not System.in.
One sentence to remember: Scanner for easy parsing, BufferedReader for speed, Console for passwords – and web apps never use System.in.
---