Core Java & OOP

Platform independence (compile once to bytecode, run on any JVM), automatic memory management (garbage collection), strong static typing with runtime safety (no raw pointers), built-in multithreading support, a huge standard library, and — since Java 8 — a functional programming layer (lambdas, streams) alongside the classic OOP model.

• Simple & object-oriented — everything (except primitives) is an object.
• Platform-independent — "write once, run anywhere" via bytecode + JVM.
• Robust — strong compile-time checking, exception handling, no explicit pointer arithmetic.
• Multithreaded — threads are a first-class language/runtime concept.
• Secure — bytecode verification, classloader sandboxing, no direct memory access.

JVM (Java Virtual Machine) is the runtime engine that executes bytecode — it's what makes Java platform-independent. JRE (Java Runtime Environment) is the JVM plus the standard class libraries needed to run Java applications. JDK (Java Development Kit) is the JRE plus development tools — compiler (javac), debugger, jar, javadoc — needed to build Java applications.

JDK  =  JRE + dev tools (javac, jdb, jar, javadoc...)
JRE  =  JVM + standard class libraries (java.lang, java.util, ...)
JVM  =  bytecode interpreter/JIT compiler + class loader + garbage collector

• Encapsulation — bundling data with the methods that operate on it, hiding internal state behind an API.
• Abstraction — exposing only what a consumer needs (interface/contract), hiding implementation detail.
• Inheritance — a class acquiring fields/behavior from a parent class, enabling reuse and "is-a" relationships.
• Polymorphism — the same call site behaving differently depending on the runtime type (or the overload chosen at compile time).

Encapsulation means keeping a class's fields private and exposing controlled access through public getters/setters or behavior methods, rather than letting outside code touch internal state directly. It matters because it lets you change the internal representation later without breaking callers, and lets you enforce invariants (validation, derived state) at a single choke point instead of trusting every caller to do the right thing.

public class BankAccount {
    private double balance; // hidden internal state

    public void deposit(double amount) {
        if (amount <= 0) throw new IllegalArgumentException("amount must be positive");
        balance += amount;
    }

    public double getBalance() { return balance; }
}

Java supports single, multilevel, and hierarchical inheritance between classes, but not multiple inheritance of classes (a class extending two classes) — that's reserved for interfaces, which a class can implement any number of.

      A
     / \
    B    C     B and C both override foo()
     \  /
      D        D extends B, C -- which foo() wins?
               Ambiguous -> Java disallows this entirely.

class D extends B { }          // single class parent only
interface X, Y { }             // multiple interfaces OK
class D implements X, Y { }    // no state clash, only behavior contracts

Since Java 8, interfaces can have default methods with bodies, which reopens a milder version of this ambiguity — see the "interface default methods" question for how that specific conflict is resolved.

Compile-time polymorphism (a.k.a. static binding) is method overloading — the compiler picks which method to call based on the argument types/count at compile time. Runtime polymorphism (dynamic binding) is method overriding — the JVM picks the actual method implementation to run based on the object's real runtime type, not its declared/reference type.

Animal a = new Dog();  // reference type Animal, runtime type Dog
a.speak();              // calls Dog.speak() -- decided at runtime (vtable dispatch)

• Method name and parameter list must be identical to the parent's method.
• Return type must be the same or a covariant (narrower subtype) of the parent's return type.
• Access modifier can only stay the same or become more visible (can't narrow from public to protected).
• Can't throw new or broader checked exceptions than the overridden method (unchecked exceptions have no such restriction).
• static, private, and final methods cannot be overridden (static/private aren't polymorphic; final explicitly forbids it).

Rule of thumb asked in interviews: use an abstract class when subclasses share common state/implementation ("is-a" with shared code); use an interface to define a capability/contract that unrelated classes can all implement ("can-do").

A constructor initializes a newly created object; it has the same name as the class and no return type — not even void — because it doesn't "return" a value, it initializes the object the JVM already allocated. If you don't write one, the compiler inserts a no-arg default constructor (only if you haven't defined any constructor yourself). Constructors can be overloaded, just like methods.

• Static variable — one copy shared across all instances of the class (class-level state, not object-level).
• Static method — belongs to the class, callable without an instance; can't use this or access instance members directly.
• Static block — runs once, when the class is first loaded/initialized, before any instance is created — used for one-time static setup.

main(String[] args) is static so the JVM can invoke it directly on the class without needing to construct an object first.

• final variable — value can be assigned once; for object references, the reference can't be reassigned (the referenced object's internal state can still change unless it's itself immutable).
• final method — cannot be overridden by a subclass.
• final class — cannot be subclassed at all (e.g. String, Integer).

== compares references for objects (are they the exact same object in memory?) or values for primitives. .equals() is a method that a class can override to compare logical/content equalityinstead. The default Object.equals() just delegates to ==, so a class that doesn't override it gets reference equality by default.

String a = new String("hi");
String b = new String("hi");
a == b;        // false -- different objects
a.equals(b);   // true  -- String overrides equals() to compare content

The contract: equal objects must produce the same hash code. Hash-based collections (HashMap, HashSet) use hashCode() first to pick a bucket, then equals() only within that bucket to confirm a match. If you override equals() but leave the default hashCode() (identity hash), two "equal" objects can land in different buckets — a map lookup with a logically equal key silently returns "not found" because it never even checks equals()against the right bucket.

class Point {
    int x, y;
    public boolean equals(Object o) { /* compares x, y */ return true; }
    // hashCode() NOT overridden -- still identity-based
}

Set<Point> seen = new HashSet<>();
seen.add(new Point(1, 1));
seen.contains(new Point(1, 1)); // false! different hashCode -> different bucket