Java.

A primitive type variable holds the value itself, while a reference type variable holds a reference that points to an object. Java has eight primitives:

• Integer types: byte, short, int, long
• Floating-point types: float, double
• boolean for true or false, and char for a single character

Each primitive has a fixed size and can never be null.

Classes, interfaces and arrays are reference types, and so are enums. Their objects are always allocated on the heap. Assigning one reference variable to another copies the reference, not the object, so both variables then point to the same object.

Where a primitive lives depends on where it is declared. A local int sits in the method's stack frame, but an int field sits inside its object on the heap.

int x = 10; // primitive - stores value 10
String str = "Hello"; // reference - stores memory address of String object

Autoboxing is the automatic conversion of a primitive to its wrapper class, such as int to Integer. Unboxing is the reverse, from Integer back to int. It lets you put primitives into collections, which only hold objects.

The compiler inserts the calls for you. Boxing an int becomes Integer.valueOf(x), and unboxing becomes x.intValue().

Two traps follow from this. Unboxing a null wrapper throws a NullPointerException. Comparing two Integer objects with == compares references, and it only seems to work for small values because Integer.valueOf caches -128 to 127.

// Autoboxing
Integer num = 100; // int to Integer
List<Integer> list = new ArrayList<>();
list.add(50); // int automatically boxed to Integer
// Unboxing
Integer wrapper = 200;
int primitive = wrapper; // Integer to int

For objects, == checks reference equality, meaning both variables point to the same object. equals() checks logical equality, meaning two objects hold the same content, as long as the class overrides it.

For primitives, == compares the values directly. For objects, the default Object.equals() behaves exactly like ==. Classes such as String and Integer override it to compare their values, and your own classes should too when two instances can be logically equal.

Identical string literals are interned, so they share one object in the string pool and s3 == s4 is true. A string built with new String is always a separate object, so compare strings with equals(). A class that overrides equals() must also override hashCode().

String s1 = new String("hello");
String s2 = new String("hello");
String s3 = "hello";
String s4 = "hello";
System.out.println(s1 == s2);        // false (different objects)
System.out.println(s1.equals(s2));   // true (same content)
System.out.println(s3 == s4);        // true (string pool)

String is immutable, while StringBuilder and StringBuffer are mutable buffers you change in place. The two buffers differ in thread safety. StringBuffer synchronizes its methods, and StringBuilder does not.

Every change to a String creates a new object, so += inside a loop copies the text again and again. A builder appends into one growing buffer instead.

StringBuilder is the default choice for building text in one thread. It has the same API as StringBuffer without the synchronization overhead. The Java documentation recommends it wherever possible, because it is faster under most implementations. StringBuffer only makes sense when several threads really append to the same buffer.

String str = "Hello";
str += " World"; // Creates new String object
StringBuilder sb = new StringBuilder("Hello");
sb.append(" World"); // Modifies existing buffer

Access modifiers control which other code can use a class or its members. Java has four levels, from most to least restrictive:

• private: visible only inside the same class.
• No modifier, called package-private or default access: visible to any class in the same package.
• protected: visible in the same package, and to subclasses in other packages.
• public: visible from anywhere.

A top-level class can only be public or package-private.

Start with the most restrictive level that works, such as private fields behind public methods, so a class can change its internals without breaking callers.

A static member belongs to the class itself and is shared by every instance. An instance member belongs to one object and needs that object to exist. There is one copy of a static variable, but every object gets its own copy of each instance variable.

Static variables are initialized once, when the class is first loaded, and you reach static members through the class name, as in Math.max(). A static method has no this, so it cannot use instance fields or call instance methods directly. An instance method can use both kinds.

Use static members for data and behaviour that do not depend on any one object, such as constants and utility methods. Shared static state is harder to test, because every test sees the same copy.

class Example {
    static int staticVar = 0;     // Class variable
    int instanceVar = 0;          // Instance variable
    static void staticMethod() {  // Can't access instance members
        // staticVar++; // OK
        // instanceVar++; // Compilation error
    }
    void instanceMethod() {       // Can access both
        staticVar++;
        instanceVar++;
    }
}

The four pillars of object-oriented programming are encapsulation, inheritance, polymorphism and abstraction. Each one is a way to manage complexity in a large code base:

1. Encapsulation bundles data with the methods that use it and hides the internal details, usually behind private fields.
2. Inheritance lets a new class reuse and extend an existing class, as when Dog extends Animal.
3. Polymorphism lets objects of different types respond to the same method call in their own way.
4. Abstraction exposes only the essential features of an object and hides how they work, through abstract classes and interfaces.

The super keyword lets a subclass call its immediate parent's constructor and reach parent members that the subclass has overridden or hidden. It has three uses:

1. super(...) calls a parent constructor. When a constructor does not call this(...) or super(...) explicitly, the compiler inserts a call to super().
2. super.method() calls the parent's version of an overridden method, often to extend that behaviour rather than replace it.
3. super.field reads a hidden field, which is a parent field hidden by a subclass field with the same name.

class Parent {
    String name = "Parent";
    void display() { System.out.println("Parent display"); }
}
class Child extends Parent {
    String name = "Child";
    Child() {
        super(); // Call parent constructor
    }
    void display() {
        super.display(); // Call parent method
        System.out.println("Parent name: " + super.name);
    }
}

ArrayList stores elements in a resizable array, while LinkedList is a doubly linked list of nodes that point to their neighbours. That layout decides which operations are cheap.

ArrayList reads any index in O(1), because it jumps straight to the slot. Adding at the end is amortized O(1), meaning an occasional resize copies the array but the average cost per add stays constant. Inserting or removing in the middle is O(n), because the later elements have to shift.

LinkedList adds and removes at either end in O(1), and in the middle only when an iterator already points there. Reaching an index is O(n), because it walks node by node from the nearer end. So add(index, x) in the middle is O(n) as well.

ArrayList is the usual default, since its per-element overhead is lower. For queue work at the ends, ArrayDeque is often faster than LinkedList.

List<String> arrayList = new ArrayList<>(Collections.nCopies(101, "item"));
List<String> linkedList = new LinkedList<>();
// ArrayList better for
String element = arrayList.get(100); // O(1)
// LinkedList better for
linkedList.add(0, "first"); // O(1)
linkedList.remove(0);       // O(1)

Checked exceptions must be caught or declared with throws, and the compiler enforces this. Unchecked exceptions need neither, so handling them is optional.

Checked exceptions extend Exception but not RuntimeException. They model failures a caller can expect and recover from, such as IOException, SQLException and ClassNotFoundException. Unchecked exceptions extend RuntimeException or Error. They usually signal bugs, such as NullPointerException, ArrayIndexOutOfBoundsException and IllegalArgumentException.

Use a checked exception when the caller can do something useful about the failure. Use an unchecked one for programming errors, where forcing every caller to catch it only adds noise.

// Checked exception - must handle
public void readFile() throws IOException {
    FileReader file = new FileReader("file.txt");
}
// Unchecked exception - optional handling
public void divide(int a, int b) {
    int result = a / b; // May throw ArithmeticException
}

Every exception in Java descends from Throwable, which splits into two branches, Error and Exception.

• Error covers serious problems such as OutOfMemoryError and StackOverflowError. A normal application should not try to catch these.
• Exception covers conditions an application may want to handle. Its subclass RuntimeException and everything below it are unchecked.

Every other subclass of Exception, such as IOException and SQLException, is checked. Error and its subclasses are unchecked too. The "Checked Exceptions" node in the tree is a grouping, not a real class. A catch (Exception e) block never catches an Error.

Throwable
├── Error (unchecked)
│   ├── OutOfMemoryError
│   └── StackOverflowError
└── Exception
    ├── Checked Exceptions
    │   ├── IOException
    │   └── SQLException
    └── RuntimeException (unchecked)
        ├── NullPointerException
        └── ArrayIndexOutOfBoundsException

throw raises an exception at a specific point in the code, while throws declares in the method signature which exceptions can reach the caller.

throw takes a single exception object, as in throw new IllegalArgumentException("Age cannot be negative"). Execution stops there, and the exception travels up the call stack until a catch block handles it. throws can list several exception types, separated by commas.

A method that can throw a checked exception must either catch it or declare it in throws. For an unchecked exception such as IllegalArgumentException, the throws clause in the example is optional and only documents the behaviour.

public void validateAge(int age) throws IllegalArgumentException {
    if (age < 0) {
        throw new IllegalArgumentException("Age cannot be negative");
    }
}

Yes. A single try can have several catch blocks, and Java runs the first one whose type matches the thrown exception. At most one of them runs.

try {
    // risky code
} catch (FileNotFoundException e) {
    // handle file not found
} catch (IOException e) {
    // handle other IO exceptions
} catch (Exception e) {
    // handle any other exception
}

Because the first match wins, order them from most specific to most general. The compiler enforces this. A catch for a subclass placed after a catch for its superclass could never run, so it is a compile-time error. In the example, FileNotFoundException must come before IOException, and Exception goes last.

One block can also catch several unrelated types joined with |, as in catch (IOException | SQLException e). Use this multi-catch form when the handling is the same for each type. Its parameter is implicitly final.