Java.

Primitive Types

Java has 8 primitive types. They are not objects — they are raw values stored directly in memory (usually on the stack, for local variables). This is different from almost everything else in Java, which is an object reference.

The 8 primitives

Key things that trip people up

• char is unsigned and 16 bits — the only unsigned primitive. char c = 'A'; int x = c; gives 65.
• byte is signed — byte b = (byte) 200; gives −56, not 200.
• Default values apply only to fields, never to local variables.
• Floating-point precision is a trap — 0.1 + 0.2 != 0.3. Never use float/double for money.

class Foo {
    int x;        // defaults to 0
    boolean b;    // defaults to false
}

void method() {
    int y;
    System.out.println(y);  // COMPILE ERROR — not initialized
}

My Doubts

Detailed Explanations

Doubt 01 — Why byte (byte) 200 is −56

Signed vs unsigned. A byte is 8 bits. With 8 bits you can represent exactly 256 different values (2⁸). The question is which 256 values?

• Unsigned (C's unsigned char): 0 to 255.
• Signed (Java's byte): −128 to 127. Half negative, half non-negative.

Java picked signed. Always. No unsigned primitives except char.

Two's complement. Java stores negative numbers using two's complement. The leftmost bit is the sign bit — 0 means non-negative, 1 means negative.

00000000 →    0
00000001 →    1
00000010 →    2
...
01111111 →  127   ← largest positive
10000000 → -128   ← most negative (sign bit flips)
10000001 → -127
...
11111110 →   -2
11111111 →   -1

The values wrap around. After 127 (01111111), adding 1 gives 10000000, which is −128, not 128.

Now: byte b = (byte) 200

200 in binary is 11001000. The cast says "truncate to 8 bits." So the byte stores 11001000. Java reads it as signed two's complement — leftmost bit is 1, so negative. To find the value:

1. Flip all bits: 11001000 → 00110111
2. Add 1: 00110111 + 1 = 00111000 = 56
3. Apply negative sign: −56

Doubt 02 — Why 0.1 + 0.2 ≠ 0.3

Computers store numbers in binary. Integers are easy — 5 in binary is 101, exact. Fractions are ugly. In decimal, we write 0.1 exactly. In binary, 0.1 is not exactly representable — it's a repeating fraction, like 1/3 in decimal.

0.1 in binary = 0.0001100110011001100110011...  (repeating forever)

So when you write double x = 0.1;, the computer stores the closest possible binary approximation in 64 bits — about 0.1000000000000000055511151231257827021181583404541015625.

When you add:

• 0.1 stored → slightly more than 0.1
• 0.2 stored → slightly more than 0.2
• 0.1 + 0.2 → 0.30000000000000004
• 0.3 stored → a different approximation

So 0.1 + 0.2 == 0.3 is false. The values differ in the 17th decimal place. == is exact.

This is IEEE 754, not a Java bug. Every modern language uses the same hardware standard — Python, JavaScript, C, C++, Go, Rust. Same result everywhere.

Why this matters for money:

double balance = 0.0;
for (int i = 0; i < 1000; i++) {
    balance += 0.01;  // add 1 paisa, 1000 times
}
System.out.println(balance);  // 9.999999999999831, not 10.00

Multiply that across millions of transactions and audits fail.

The fix: BigDecimal. Stores numbers as exact decimal digits + a scale, not as binary approximations.

import java.math.BigDecimal;

BigDecimal a = new BigDecimal("0.1");   // pass as STRING!
BigDecimal b = new BigDecimal("0.2");
BigDecimal sum = a.add(b);
System.out.println(sum);  // 0.3 exactly
System.out.println(sum.equals(new BigDecimal("0.3")));  // true

Critical gotcha: always construct BigDecimal from a String, not a double. new BigDecimal(0.1) feeds it the already-corrupted binary approximation. Use new BigDecimal("0.1") or BigDecimal.valueOf(0.1) (which internally calls Double.toString first).

Q&A — Check Yourself

byte b = (byte) 130;
System.out.println(b);

byte b = (byte) 128;
System.out.println(b);

double a = 0.1 + 0.2;
double b = 0.3;
System.out.println(a == b);

Wrapper Classes & Autoboxing

Every primitive type has a corresponding wrapper class — an object that "wraps" the primitive value. Wrappers exist because Java's generics and collections only work with objects, not primitives.

The 8 wrappers

Naming gotcha: mostly capitalized, but int → Integer and char → Character (not Int and Char).

List<int> list = new ArrayList<>();        // COMPILE ERROR
List<Integer> list = new ArrayList<>();    // OK

int vs Integer

That last row is where bugs live — we'll see why in Topic 03.

Wrapper objects are immutable

Once you create an Integer(5), that object always represents 5. If you do i = i + 1, you're creating a new Integer object and pointing i to it. The old one is unchanged. This matters for thread safety and for the cache trick coming up.

Autoboxing & Unboxing

Java automatically converts between primitives and wrappers so you don't have to write conversion code.

• Autoboxing: primitive → wrapper
• Unboxing: wrapper → primitive

Integer i = 5;            // autoboxing: int 5 → Integer.valueOf(5)
int x = i;                // unboxing: i.intValue() → int

List<Integer> list = new ArrayList<>();
list.add(10);             // autoboxing
int first = list.get(0);  // unboxing

Under the hood, the compiler rewrites Integer i = 5; as Integer i = Integer.valueOf(5); — not new Integer(5). That distinction is the doorway into the Integer cache.

Hidden costs of autoboxing

1. NullPointerException on unboxing

Integer i = null;
int x = i;        // NullPointerException at runtime!

Compiler generates i.intValue(), and calling a method on null blows up. Very common bug with Map.get():

Map<String, Integer> counts = new HashMap<>();
int n = counts.get("missing");   // NPE

2. Performance

Long sum = 0L;                    // Long, not long!
for (long i = 0; i < 1_000_000; i++) {
    sum += i;                     // autoboxes/unboxes every iteration
}
// Allocates ~1 million Long objects. Slow.

Fix: use long sum = 0L; (primitive).

My Doubts

Q&A — Check Yourself

The Integer Cache

Remember that autoboxing uses Integer.valueOf(x), not new Integer(x). Here's what Integer.valueOf() actually does inside the JDK:

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high) {
        return IntegerCache.cache[i + (-IntegerCache.low)];
    }
    return new Integer(i);
}

That IntegerCache is a static array of pre-made Integer objects for the values −128 to 127. The JDK creates them once when the class loads and reuses them forever.

Why it matters: == comparison

== on objects compares references, not values.

Integer a = 100;
Integer b = 100;
System.out.println(a == b);    // true  — same cached object

Integer c = 200;
Integer d = 200;
System.out.println(c == d);    // false — different heap objects

The fix: always use .equals()

Integer c = 200;
Integer d = 200;
System.out.println(c.equals(d));   // true — compares values
System.out.println(c == d);        // false — compares references

Rule of thumb: never use == on wrapper objects. Always .equals(), or Objects.equals() for null safety.

Why −128 to 127?

1. Common values. Most integers in real code are small — loop counters, indices, ages, status codes.
2. It matches byte range. Anything that fits in a byte is cached.

You can expand the upper bound via -XX:AutoBoxCacheMax=N. Production code shouldn't rely on this.

Other wrapper caches

The deepest gotcha: new Integer(x) skips the cache

Integer a = 100;                 // cached
Integer b = new Integer(100);    // brand new object
System.out.println(a == b);      // false! Both are 100.

new Integer() always allocates fresh — which is why it was deprecated in Java 9 and removed in later versions.

Q&A — Check Yourself

Integer a = 100;
Integer b = 100;
System.out.println(a == b);

Integer a = 200;
Integer b = 200;
System.out.println(a == b);

Integer a = 127;
Integer b = new Integer(127);
System.out.println(a == b);
System.out.println(a.equals(b));

Map<String, Integer> counts = new HashMap<>();
counts.put("apple", 5);
int n = counts.get("banana");
System.out.println(n);

public boolean sameId(Integer x, Integer y) {
    return x == y;
}

String Immutability, the Pool & intern()

This topic has the same "shared object" theme as the Integer cache — pooled instances for common values, fresh allocations otherwise. Once you see the pattern, both topics click together.

Part 1 — Strings are immutable

Immutable means: once a String object is created, its contents cannot be changed. Every "modification" actually creates a new String.

String s = "hello";
s.toUpperCase();           // returns "HELLO" — but doesn't change s
System.out.println(s);     // still "hello"

s = s.toUpperCase();       // now s points to the NEW "HELLO" object
System.out.println(s);     // "HELLO"

Methods like toUpperCase(), replace(), substring(), trim(), concat() — none of them modify the original. They all return new String objects.

Why immutable? Four real reasons

1. Security

Strings are everywhere — file paths, URLs, connection strings, class names. If they were mutable, a malicious thread could change a path after a security check but before the file open. Immutability eliminates this entire bug class.

2. Thread safety

Immutable objects are inherently thread-safe. No locks needed. You can share a String across 1000 threads without any synchronization.

3. Hashcode caching

String caches its hashcode after first computation. Makes it incredibly fast as a HashMap key. If strings were mutable, the cached hashcode could go stale.

// Inside String.java:
private int hash; // cached hashcode

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        // compute and cache
        hash = h = ...;
    }
    return h;
}

4. The String pool

Which leads us to part 2.

Part 2 — The String Pool

Just like the Integer cache, Java keeps a special memory region called the String pool (a.k.a. "string intern pool"). It holds unique string literals.

When you write a string literal, Java checks the pool:

• If the string already exists → return the existing reference
• If not → create it, add to pool, return the new reference

String a = "hello";
String b = "hello";
System.out.println(a == b);    // true — same pool object

But new String(...) always allocates

String a = "hello";              // pool
String b = new String("hello");  // heap — brand new object
System.out.println(a == b);      // false — different references
System.out.println(a.equals(b)); // true — same content

Same pattern as new Integer(100) vs autoboxed 100. There's almost never a reason to call new String(literal) in real code.

Where does the pool live?

• Java 7+: in the heap (used to be in PermGen, which had memory leak issues)
• Java 8+: still heap, but String uses byte[] instead of char[] internally (compact strings — saves ~half the memory for ASCII)

The pool is garbage-collected — entries can be removed if nothing references them.

Part 3 — The intern() method

intern() lets you manually add a string to the pool, or get the pool reference for an equal string already there.

String a = new String("hello");        // heap object
String b = a.intern();                  // returns pool reference
String c = "hello";                     // pool literal

System.out.println(a == b);  // false — a is heap, b is pool
System.out.println(b == c);  // true  — both pool references

Contract: if a string equal to this one is already in the pool, return that reference; otherwise add this one and return it. After intern(), s.intern() == "literal" is true for any equal string.

The classic gotcha — concatenation

String a = "hello";
String b = "hel" + "lo";        // COMPILE-TIME fold
System.out.println(a == b);     // true — both pool

String x = "hel";
String y = x + "lo";            // RUNTIME — uses StringBuilder
String z = "hello";
System.out.println(z == y);     // false — y is on heap
System.out.println(z == y.intern()); // true — intern brings it to pool

The rule:

• Compile-time constant expressions → folded into a single pool entry by the compiler
• Runtime concatenation (with variables) → built on the heap via StringBuilder.toString()

A subtle extension: marking the variable final makes it a compile-time constant, which changes the behavior:

final String x = "hel";
String y = x + "lo";
System.out.println("hello" == y);  // true! final inlines the value

Why care? Memory.

If you're parsing millions of strings (logs, JSON, indexes) where many are duplicates, intern() can save massive memory by ensuring only one copy exists.

// Naive — 1M Strings even if most are duplicates
List<String> logLevels = new ArrayList<>();
for (LogEntry e : entries) {
    logLevels.add(e.getLevel());  // 1M copies of "INFO"
}

// Memory-efficient
for (LogEntry e : entries) {
    logLevels.add(e.getLevel().intern());  // one "INFO" in memory
}

But intern() isn't free — it does a pool lookup. Use it when you know you have lots of duplicates.

My Doubts

Q&A — Check Yourself

String a = "java";
String b = "java";
System.out.println(a == b);
System.out.println(a.equals(b));

String a = "java";
String b = new String("java");
System.out.println(a == b);
System.out.println(a == b.intern());

String a = "hello";
String b = "hel" + "lo";
String c = "hel";
String d = c + "lo";
System.out.println(a == b);
System.out.println(a == d);

String name = "ravi";
name.toUpperCase();
System.out.println(name);   // prints "ravi", not "RAVI"

String vs StringBuilder

This builds directly on String immutability. Every "modification" to a String creates a new object — elegant in isolation, catastrophic in a loop. StringBuilder is the escape hatch: mutable, single-object, fast.

The problem with String concatenation

Watch what actually happens here:

String result = "";
  for (int i = 0; i < 5; i++) {
      result = result + i;
  }
  // result = "01234"

Looks innocent. Trace what happens to the heap:

5 String objects allocated, 4 immediately garbage. And it gets quadratically worse. For N iterations, the total characters copied is 1 + 2 + 3 + ... + N = N(N+1)/2 = O(N²), because each new String has to copy all the previous characters.

For N = 1,000,000 that's ~500 billion character copies. The GC will scream.

Enter StringBuilder

StringBuilder is a mutable sequence of characters. You can append, modify, and insert — all without creating new objects (most of the time). Internally it holds a char[] (or byte[] in Java 9+) and an int length.

StringBuilder sb = new StringBuilder();
  for (int i = 0; i < 5; i++) {
      sb.append(i);
  }
  String result = sb.toString();   // "01234"

One StringBuilder object. One toString() at the end. No garbage in between.

How StringBuilder works internally

A StringBuilder holds:

• A backing array (default capacity: 16 characters)
• A current length (how much of the array is used)

When you append():

• If there's room → just write at position length, bump length
• If the array is full → allocate a new, bigger array (typically oldCapacity * 2 + 2), copy old contents in, then append

Most appends are O(1). The occasional resize is O(n), but amortized across many appends it's still O(1) per character. Way better than String's O(n²).

StringBuilder sb = new StringBuilder();  // capacity 16
  sb.append("hello");                      // length=5, capacity=16
  sb.append(" world");                     // length=11, capacity=16
  sb.append(" of streams and threads");   // length=33 → resize to 34

Performance tip: if you know the final size roughly, pre-size:

StringBuilder sb = new StringBuilder(1024);  // pre-allocate 1KB

Avoids all the intermediate resize copies. Big win for hot paths.

The useful API

StringBuilder sb = new StringBuilder();

  sb.append("hello");          // "hello"
  sb.append(' ').append(42);   // "hello 42" — chainable, any type
  sb.insert(0, ">> ");         // ">> hello 42"
  sb.delete(0, 3);             // "hello 42"
  sb.reverse();                // "24 olleh"
  sb.replace(0, 2, "XX");      // "XX olleh"
  sb.setLength(2);             // "XX" — truncate
  sb.charAt(0);                // 'X'
  sb.length();                 // 2
  sb.capacity();               // backing array size (may be > length)

  String result = sb.toString();   // convert to immutable String

All of these mutate sb in place (except toString()). append() returns sb itself for chaining, not a new object.

What about StringBuffer?

StringBuffer is the older sibling. Same API, same behavior — except every method is synchronized (thread-safe).

Rule of thumb: use StringBuilder. StringBuffer exists for backward compatibility (since Java 1.0). StringBuilder was added in Java 5 because synchronizing every operation is wasteful for the common single-threaded case. In multi-threaded code, the standard pattern is "each thread has its own builder, merge at the end" — which avoids lock contention entirely.

The compiler is smarter than you think

String result = "hello" + name + " you are " + age;

This doesn't actually do naive String concatenation. The compiler rewrites it to use a StringBuilder (or StringConcatFactory in Java 9+) behind the scenes. A single concatenation expression is fine.

The problem only appears when you concatenate across separate statements, especially in loops:

// BAD — compiler can't optimize across iterations
  String result = "";
  for (int i = 0; i < 1000; i++) {
      result = result + "x";   // O(n²)
  }

  // GOOD — explicit StringBuilder
  StringBuilder sb = new StringBuilder();
  for (int i = 0; i < 1000; i++) {
      sb.append("x");          // O(n)
  }
  String result = sb.toString();

The compiler can't lift the StringBuilder out of the loop — because in principle, someone could observe the intermediate value of result. So you have to do it yourself.

Modern alternatives

1. String.join() — for joining with a separator

String csv = String.join(",", "a", "b", "c");   // "a,b,c"
  String csv2 = String.join(",", List.of("a", "b", "c"));

2. String.format() — for templates

String msg = String.format("User %s is %d years old", name, age);

Slow internally (regex-based parsing) — fine for one-offs, bad in hot loops.

3. Text blocks (Java 15+)

String json = """
      {
        "name": "%s",
        "age": %d
      }
      """.formatted(name, age);

Decision table — when to use what

My Doubts

Q&A — Check Yourself

String result = "";
  for (int i = 0; i < n; i++) {
      result = result + "x";
  }

StringBuilder sb = new StringBuilder("hello");
  StringBuilder sb2 = sb.append(" world");
  System.out.println(sb == sb2);
  System.out.println(sb);

StringBuilder sb = new StringBuilder();
  sb.append("a");
  sb.append(",");
  sb.append("b");
  sb.append(",");
  sb.append("c");
  String csv = sb;
  System.out.println(csv);

public String buildReport(List<String> lines) {
      String result = "";
      for (String line : lines) {
          result = result + line + "\n";
      }
      return result;
  }

StringBuilder sb = new StringBuilder(lines.size() * 64);
  for (String line : lines) {
      sb.append(line).append('\n');
  }
  return sb.toString();

public class Logger {
      private StringBuilder buffer = new StringBuilder();

      public void log(String msg) {
          buffer.append(msg).append("\n");
      }

      public String flush() {
          String result = buffer.toString();
          buffer.setLength(0);
          return result;
      }
  }

public synchronized void log(String msg) {
      buffer.append(msg).append("\n");
  }

  public synchronized String flush() {
      String result = buffer.toString();
      buffer.setLength(0);
      return result;
  }