Why does Java not expose explicit pointers?

Java chose references over pointers for:

• Safety. No pointer arithmetic means no buffer overflows or memory corruption.
• GC compatibility. The garbage collector moves objects during compaction. References are updated automatically; raw pointers would become invalid.
• Simplicity. Developers work with object references, not memory addresses. Null access is a clean NullPointerException, not a segmentation fault.

What is the difference between a reference and a pointer?

| Feature | Java reference | C/C++ pointer |
|---|---|---|
| Arithmetic | Not possible | ptr + 1 moves to next memory slot |
| Raw address | Hidden | Visible (&variable) |
| Null access | NullPointerException (clean crash) | Undefined behavior (corruption/segfault) |
| Buffer overflow | Impossible (bounds checking) | Common vulnerability |
| Dangling pointer | Impossible (GC handles lifetime) | Common bug (use-after-free) |
| GC compatibility | Yes (GC moves objects freely) | No (address changes break pointers) |

Why does the GC need this?

Modern garbage collectors (G1, ZGC) compact the heap by moving live objects together. This updates all references to the moved objects. If Java exposed raw pointers, every move would invalidate existing pointers.

// Java: GC can move the Account object
Account a = new Account("SAV2001");
// GC moves the object from address 0x1000 to 0x2000
// 'a' is silently updated to point to 0x2000
System.out.println(a.getAccountId());  // works perfectly

// C: if you held a raw pointer to 0x1000, it is now dangling

When do you need low-level access?

// JNI: call native C code (e.g., hardware drivers, crypto libraries)
// sun.misc.Unsafe: direct memory access (used internally by JDK and frameworks)
// java.nio.ByteBuffer.allocateDirect: off-heap memory for I/O

These bypass safety guarantees and should only be used by framework authors, not application code.

What should a senior engineer know?

• Compressed oops (ordinary object pointers) on 64-bit JVMs with <32GB heap use 4-byte references instead of 8-byte. This is invisible to you but saves significant memory.
• Project Panama (Java 22+) provides a safe alternative to JNI for calling native code: the Foreign Function & Memory API.
• VarHandle (Java 9+) provides memory fence operations without Unsafe.

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.