Java Questions

Java is an object-oriented, platform-independent programming language that allows developers to write code once and run it anywhere (WORA). It features automatic memory management through garbage collection, strong typing, and a rich standard library. Unlike languages like C++, Java abstracts away hardware complexities and provides built-in security features. Its platform independence is achieved through the Java Virtual Machine (JVM), which interprets bytecode across different operating systems.

WORA means Java code compiled into bytecode can run on any platform with a JVM installed without modification or recompilation. When you compile Java source code, it creates platform-independent bytecode (.class files) instead of native machine code. The JVM on each platform translates this bytecode into platform-specific instructions at runtime. This architecture eliminates the need to rewrite code for different operating systems, making Java highly portable and versatile.

JDK (Java Development Kit) is a complete software development environment containing JRE plus development tools like compiler (javac), debugger, and documentation generator (javadoc). JRE (Java Runtime Environment) provides the minimum requirements for running Java applications, including JVM, core libraries, and supporting files but no development tools. JVM (Java Virtual Machine) is the engine that executes bytecode and is a component of JRE. In summary: JDK = JRE + Development Tools, JRE = JVM + Libraries.

This is Java's program entry point where execution begins. 'public' makes it accessible from anywhere, allowing JVM to call it. 'static' means it belongs to the class itself, not instances, so JVM can invoke it without creating an object. 'void' indicates no return value. 'main' is the specific method name JVM looks for. 'String[] args' is a parameter accepting command-line arguments as an array of strings. This exact signature is mandatory for the JVM to recognize and execute the program.

Classpath is an environment variable or parameter telling JVM and compiler where to find user-defined classes and packages. It's a list of directories, JAR files, or ZIP files containing .class files. Set using CLASSPATH environment variable, -cp or -classpath command-line option, or manifest file in JARs. JVM searches classpath in order to load classes. Missing classes cause ClassNotFoundException or NoClassDefFoundError. Proper classpath configuration is crucial for application execution. Modern build tools like Maven and Gradle manage classpaths automatically. Understanding classpath helps debug loading issues.

PATH is an operating system environment variable specifying directories containing executable programs, used by OS to locate executables like java, javac. CLASSPATH is Java-specific, telling JVM where to find compiled Java classes (.class files) and packages. PATH contains binary executables, CLASSPATH contains .class files, JAR files. Set PATH to run Java commands from any directory. Set CLASSPATH so JVM can find application classes. PATH is OS-level, CLASSPATH is Java-level. Incorrect PATH prevents running Java commands; incorrect CLASSPATH causes ClassNotFoundException. Both can be set as environment variables or command-line parameters.

The JVM is a virtual machine that executes Java bytecode, providing an abstraction layer between compiled Java programs and the underlying hardware/operating system. It loads class files, verifies bytecode for security, interprets or compiles bytecode to native code using JIT compilation, manages memory allocation and garbage collection, and provides runtime environment. The JVM enables platform independence by translating bytecode into machine-specific instructions, making Java applications portable across different systems.

Garbage collection is Java's automatic memory management process that identifies and reclaims memory occupied by objects no longer referenced by the program. The garbage collector runs periodically, marking reachable objects, sweeping unreferenced ones, and optionally compacting memory. Unlike languages like C++, developers don't manually free memory. Garbage collection prevents memory leaks and dangling pointers but introduces pause times. Different GC algorithms (Serial, Parallel, G1, ZGC) offer trade-offs between throughput and latency. System.gc() suggests collection but doesn't guarantee immediate execution.

The Java Memory Model (JMM) defines how threads interact with memory, specifying when changes by one thread become visible to others. It establishes happens-before relationships ensuring memory operation ordering across threads. The JMM addresses visibility (when writes are visible to other threads), atomicity (operations completed without interruption), and ordering (preventing instruction reordering). Key concepts include volatile variables, synchronization, final fields, and happens-before relationships. Understanding JMM is crucial for writing correct concurrent code, avoiding race conditions, and ensuring thread-safe operations without explicit synchronization overhead.

The JVM divides memory into several areas: Heap Memory stores objects and instance variables, shared among threads, and managed by garbage collection. Stack Memory contains local variables and method call frames, with each thread having its own stack. Method Area (Metaspace in Java 8+) stores class metadata, static variables, and constant pool, shared across threads. Program Counter Register holds the current instruction address for each thread. Native Method Stack is for native method execution. This organization enables efficient memory management, thread isolation, and garbage collection.

Heap memory stores objects and instance variables, dynamically allocated at runtime, shared by all threads, and managed by garbage collector. It's larger but slower to access. Objects remain until garbage collected. Stack memory stores primitive local variables and object references, organized as Last-In-First-Out, thread-specific (each thread has its own), automatically allocated/deallocated when methods execute, and faster to access. Variables are automatically destroyed when their scope ends. StackOverflowError occurs when stack is full, while OutOfMemoryError indicates heap exhaustion. Understanding this helps optimize memory usage.

The finalize() method, defined in Object class, is called by garbage collector before reclaiming object memory, intended for cleanup operations like closing files or releasing resources. However, finalize() is deprecated (Java 9+) and problematic: unpredictable execution timing, no guarantee of execution, performance overhead, can resurrect objects, and complexity. Better alternatives: try-with-resources for AutoCloseable resources, explicit close() methods, cleaner API (Java 9+), or shutdown hooks. Finalize should not be used in modern Java. It's executed only once and may prevent timely garbage collection. Use explicit resource management instead.

ClassLoader is responsible for dynamically loading Java classes into JVM at runtime. Three built-in classloaders exist in hierarchy: Bootstrap (loads core Java classes from rt.jar), Extension (loads from ext directory), and System/Application (loads from classpath). ClassLoader follows delegation model: requests delegate to parent before loading. Custom classloaders enable loading classes from non-standard sources, implementing hot-swapping, class isolation, and security policies. Methods include loadClass(), findClass(), defineClass(). Understanding classloaders is important for frameworks, application servers, plugin systems, and debugging ClassNotFoundException issues. Each class remembers its loader.

JIT compiler is a component of JVM that improves performance by compiling bytecode into native machine code at runtime during program execution. JVM initially interprets bytecode, but JIT identifies frequently executed code (hot spots) and compiles them to native code for faster execution. Types include C1 (client, fast compilation) and C2 (server, aggressive optimization). Tiered compilation uses both. Benefits include near-native performance, adaptive optimization based on runtime behavior, and platform independence maintained. JIT balances startup time and peak performance. Modern JVMs use sophisticated profiling to optimize critical paths.

Major GC algorithms include: Serial GC (single-threaded, stop-the-world, simple applications), Parallel GC (multiple threads for GC, throughput-oriented, multi-core systems), CMS (Concurrent Mark Sweep - concurrent with application, low pause times, deprecated in Java 14), G1 GC (Garbage First - default from Java 9, region-based, predictable pause times, large heaps), ZGC (scalable low-latency, concurrent, very large heaps, minimal pause), and Shenandoah (low pause times, concurrent compaction). Choose based on application requirements: throughput vs latency, heap size, and pause time tolerance. Tuning involves heap sizing, generation ratios, and GC-specific parameters.

Heap stores application objects and instance variables, divided into Young Generation (Eden, Survivor spaces) and Old Generation, with size configured by -Xms and -Xmx flags, and managed by garbage collection. Metaspace (replaced PermGen in Java 8) stores class metadata, static variables, constant pool, and JIT-compiled code. Metaspace uses native memory (not heap), grows dynamically, has no default size limit, and is garbage collected when classes unload. OutOfMemoryError: Heap space indicates heap exhaustion; OutOfMemoryError: Metaspace indicates metadata area issues. Proper sizing prevents memory issues.

JIT (Just-In-Time) compiles bytecode to native code during runtime, enabling adaptive optimization based on execution patterns, providing better peak performance, but causing slower startup and warmup time. AOT (Ahead-Of-Time) compiles bytecode to native code before runtime during build phase, offering faster startup, predictable performance, smaller runtime footprint, but no runtime optimizations. GraalVM Native Image is popular AOT compiler for Java. Use AOT for serverless, microservices with fast startup requirements, CLI tools. Use JIT for long-running applications needing peak performance. Modern Java supports both approaches.

Java has eight primitive data types: byte (8-bit integer), short (16-bit integer), int (32-bit integer), long (64-bit integer), float (32-bit floating point), double (64-bit floating point), boolean (true/false), and char (16-bit Unicode character). These primitives store actual values directly in memory rather than references, providing better performance and lower memory usage. Unlike objects, primitives cannot be null and have default values (0 for numeric types, false for boolean, \u0000 for char).

Wrapper classes convert primitive types into objects, providing an object-oriented way to work with primitives. Each primitive has a corresponding wrapper: Integer for int, Double for double, Boolean for boolean, Character for char, etc. They're essential for using primitives in Collections (which only store objects), enabling features like null values, providing utility methods for type conversion and parsing, supporting autoboxing/unboxing, and facilitating serialization. Wrapper classes bridge the gap between primitive types and object-oriented programming.

Autoboxing is automatic conversion of primitive types to their wrapper class objects (int to Integer), while unboxing is the reverse (Integer to int). This feature, introduced in Java 5, eliminates manual conversion, making code cleaner. For example, adding an int to an ArrayList<Integer> automatically boxes it. However, excessive autoboxing/unboxing can impact performance due to object creation overhead and can cause NullPointerException if null wrapper objects are unboxed. Understanding this mechanism is important for writing efficient code and debugging unexpected null issues.

The four pillars of OOP are: Encapsulation - bundling data and methods that operate on that data within a single unit (class) while hiding internal implementation details. Inheritance - ability of a class to inherit properties and methods from a parent class, promoting code reuse. Polymorphism - ability of objects to take multiple forms, allowing one interface to be used for different data types. Abstraction - hiding complex implementation details and showing only essential features to users through interfaces and abstract classes.

A class is a blueprint or template for creating objects that defines the structure (fields/attributes) and behavior (methods) that objects of that type will have. You define a class using the 'class' keyword followed by the class name and curly braces containing member variables and methods. For example: 'class Dog { String name; int age; void bark() { } }'. Classes support encapsulation, inheritance, and polymorphism. Multiple objects (instances) can be created from a single class, each with its own state.

An object is an instance of a class created at runtime using the 'new' keyword. It represents a real-world entity with state (instance variables) and behavior (methods). Objects occupy memory on the heap and contain actual values for the attributes defined in their class. Multiple objects can be created from the same class blueprint, each maintaining independent state. Objects interact with each other through method calls, enabling complex application logic. Objects are the fundamental building blocks of object-oriented programming in Java.

A constructor is a special method with the same name as the class and no return type, invoked when an object is created using the 'new' keyword. It initializes the object's state by setting initial values for instance variables. Constructors can be overloaded to provide multiple ways of object initialization. If no constructor is defined, Java provides a default no-argument constructor. Constructors can call other constructors using 'this()' or parent constructors using 'super()', enabling flexible object initialization patterns.

Inheritance is an OOP principle where a new class (subclass/child) inherits properties and methods from an existing class (superclass/parent) using the 'extends' keyword. It promotes code reusability, establishes an IS-A relationship, and supports hierarchical classification. Java supports single inheritance (one parent class) but allows multiple interface implementation. The child class can access parent's non-private members, override methods, and add new functionality. Inheritance facilitates polymorphism and creates a logical class hierarchy, making code more maintainable and organized.

Abstract classes can have both abstract and concrete methods, constructor, instance variables, and any access modifier. They're used when classes share a common base with partial implementation. Interfaces (pre-Java 8) contained only abstract methods and constants, but now can have default, static, and private methods. A class can implement multiple interfaces but extend only one abstract class. Interfaces define a contract for what a class can do, while abstract classes provide a base for what classes are. Use interfaces for capabilities, abstract classes for inheritance hierarchy.

Encapsulation bundles data (variables) and methods operating on that data within a class, hiding internal implementation details from outside access. It's achieved using access modifiers: private (class-only access), protected (package and subclass access), default/package-private (package access), and public (everywhere access). Typically, instance variables are marked private and accessed through public getter/setter methods, providing controlled access and validation. Benefits include data hiding, increased flexibility, easier maintenance, and controlled modification. Encapsulation is fundamental to building secure, modular, and maintainable code.

Polymorphism allows objects to take multiple forms and enables one interface to be used for different underlying data types. It exists in two forms: compile-time (method overloading) and runtime (method overriding). Runtime polymorphism occurs when a parent class reference points to a child class object, and the actual method called is determined at runtime. This enables writing flexible, extensible code where behavior changes based on the object's actual type. Polymorphism is crucial for designing loosely coupled systems and implementing design patterns like Strategy and Factory.

Abstraction separates interface from implementation, showing only essential features while hiding complex implementation details. It's achieved through abstract classes (using 'abstract' keyword with partial implementation) and interfaces (pure abstraction). Abstract methods have no body and must be implemented by subclasses. Abstraction reduces complexity, increases reusability, enables loose coupling, and allows focusing on what an object does rather than how it does it. For example, a Vehicle abstract class defines a move() method without specifying whether it's a car or airplane.

After Java 8, interfaces can have default and static methods with implementations, narrowing the gap with abstract classes. Key differences: classes extend one abstract class but implement multiple interfaces (multiple inheritance of type). Abstract classes can have constructors, instance variables, any access modifiers; interfaces cannot have constructors, can only have public static final variables, and methods are public by default. Use abstract classes for IS-A relationships and sharing code among related classes. Use interfaces for defining contracts, capabilities (CAN-DO), and achieving loose coupling. Abstract classes support state, interfaces support behavior.

Covariant return type allows overridden methods to return a subtype of the return type declared in the parent class method. Introduced in Java 5, it enables more specific return types in subclasses without violating override rules. For example, if parent method returns Animal, child can return Dog (Dog extends Animal). Benefits include type-safe method chaining, eliminating unnecessary casting, more intuitive APIs, and enabling fluent interfaces. Covariant return types work with classes and interfaces, improving flexibility in object-oriented design. This feature is commonly used in builder patterns and factory methods.

Diamond problem occurs when a class inherits from two classes that share a common ancestor, creating ambiguity about which version of inherited methods to use. Java prevents this by not supporting multiple class inheritance. However, multiple interface inheritance is allowed. Java 8+ addresses potential conflicts: if a class implements multiple interfaces with same default methods, the class must override the method to resolve ambiguity. If one interface extends another with same default method, the more specific (subinterface) wins. If both are at same level, compilation error occurs unless overridden. Interface-only approach avoids traditional diamond problem.

Instance variables are declared inside a class but outside methods, belong to object instances, stored in heap memory, automatically initialized to default values, and have class-level scope accessible to all instance methods. Local variables are declared inside methods/blocks, exist only during method execution, stored in stack memory, must be explicitly initialized before use, and have limited scope only within the declaring method or block. Instance variables persist as long as the object exists, while local variables are destroyed when method execution completes.

Static members belong to the class itself rather than object instances, created when the class loads and shared among all instances. Static variables (class variables) have only one copy in memory regardless of object count, useful for constants and shared data. Static methods can be called without creating objects, cannot access instance variables directly, and are invoked using class name. The 'static' keyword is used for memory management and utility methods. Common examples include Math.max(), System.out, and static counters tracking object creation.

Method overloading allows a class to have multiple methods with the same name but different parameter lists (different number, type, or order of parameters). This is compile-time polymorphism where the compiler determines which method to call based on method signature. Return type alone cannot differentiate overloaded methods. Overloading improves code readability by using the same method name for similar operations on different data types. Example: a Calculator class might have add(int, int), add(double, double), and add(int, int, int) methods.

Method overriding occurs when a subclass provides a specific implementation of a method already defined in its parent class with the same signature (name, parameters, return type). This is runtime polymorphism where the actual method called is determined at runtime based on the object type. The @Override annotation helps prevent errors and improves code readability. Overridden methods must have the same or more accessible visibility. The super keyword can call the parent's version. Overriding enables polymorphic behavior and customization of inherited behavior.

The == operator compares reference addresses for objects (checks if two references point to the same memory location) and compares actual values for primitives. The equals() method compares object content based on the class's implementation. For String and wrapper classes, equals() compares values. Custom classes should override equals() to define meaningful equality. Using == for String comparison can give unexpected results due to string pooling. For objects, always use equals() for content comparison and == only for reference comparison or primitive value checking.

Immutability means object state cannot be modified after creation. Immutable objects are inherently thread-safe requiring no synchronization, easier to reason about, safe to use as HashMap keys, prevent unintended side effects, and enable caching/sharing. To create immutable classes: declare class final, make fields private final, initialize in constructor, don't provide setters, return defensive copies of mutable objects, and prevent method overriding. Examples include String, Integer, and BigDecimal. Immutability is fundamental to functional programming, concurrent systems, and preventing bugs. However, creating new objects for modifications can impact performance.

The equals-hashCode contract states: if two objects are equal according to equals(), they must have the same hashCode(). However, objects with same hashCode() need not be equal (hash collision). When overriding equals(), always override hashCode(). This contract is critical for hash-based collections like HashMap, HashSet. Violations cause incorrect behavior in collections - objects won't be found or duplicates may exist. Implementation guidelines: use same fields in both methods, ensure consistency, immutable fields preferred. IDE-generated or Objects.hash() methods help avoid errors. This contract maintains collection integrity.

Shallow copy creates a new object but copies references to nested objects, so changes to nested objects affect both copies. It's created using clone() (Cloneable interface) or copy constructors. Deep copy creates a new object and recursively copies all nested objects, creating completely independent copies. Changes don't affect the original. Deep copy requires custom implementation: manual copying, serialization/deserialization, or libraries like Apache Commons. Shallow copy is faster and sufficient for immutable nested objects. Deep copy is necessary for mutable nested objects to ensure independence. Choose based on whether nested object sharing is acceptable.

Enums are special classes representing fixed sets of constants, providing type-safe alternatives to int constants. Enums can have fields, constructors, and methods. They're implicitly final and extend java.lang.Enum. Each enum constant is a public static final instance. Benefits include compile-time type safety, namespace for constants, ability to add methods and fields, use in switch statements, and iteration through values(). Enums can implement interfaces, have constructors (private only), and maintain singleton property. Common uses: days of week, status codes, directions, and configuration options. EnumSet and EnumMap provide specialized collections.

Java is strictly pass-by-value, meaning method parameters receive copies of argument values. For primitives, the actual value is copied, so modifications don't affect the original. For objects, the reference value (memory address) is copied, so both original and copy reference the same object. Modifications to the object affect the original, but reassigning the parameter doesn't affect the original reference. This often confuses developers who think Java is pass-by-reference for objects. Key point: you can't make a parameter reference a different object permanently. Understanding this prevents bugs and clarifies method behavior.

The String class represents character sequences and is immutable, meaning once created, its content cannot be changed. Any operation that appears to modify a String actually creates a new String object. Immutability provides benefits like thread safety (no synchronization needed), security (strings can't be modified after creation), caching efficiency (string pool), and reliable hash keys for HashMap. String immutability means operations like concatenation can be inefficient for frequent modifications, which is why StringBuilder and StringBuffer exist for mutable string operations.

String is immutable; any modification creates a new object, making it inefficient for frequent changes but thread-safe. StringBuilder is mutable (modifiable), not thread-safe, and faster for single-threaded string manipulation since it doesn't require synchronization overhead. StringBuffer is mutable and thread-safe (synchronized), suitable for multi-threaded environments but slower than StringBuilder due to synchronization. Use String for constant values, StringBuilder for single-threaded string building, and StringBuffer when thread safety is required. StringBuilder offers best performance for concatenation operations.

String literals ("text") are stored in String Pool (special memory area in heap/metaspace), enabling string interning where identical literals share the same object reference. String objects created with 'new String()' always create new objects in heap, even if identical strings exist. Literals are more memory-efficient through pooling. Using == on literals may return true if same content, while == on objects returns false unless same reference. intern() method moves String object to pool. Prefer literals for better performance and memory usage. String pool enables efficient string comparison and memory sharing.

The try-catch-finally block handles exceptions to maintain normal program flow. The try block contains code that might throw exceptions. Catch blocks handle specific exception types, executing when matching exceptions occur. Multiple catch blocks can handle different exception types. The finally block always executes regardless of whether an exception occurred, making it ideal for cleanup operations like closing files or database connections. Even if try/catch blocks have return statements, finally executes first. This mechanism prevents program crashes and enables graceful error handling and resource management.

Checked exceptions are checked at compile-time and must be either caught with try-catch or declared using throws in the method signature. They represent recoverable conditions like IOException or SQLException. Unchecked exceptions (RuntimeException subclasses) are not checked at compile-time and typically indicate programming errors like NullPointerException or ArrayIndexOutOfBoundsException. Unchecked exceptions don't require explicit handling. Use checked exceptions for recoverable conditions that calling code should handle, and unchecked exceptions for programming bugs that should be fixed rather than caught.

The 'throw' keyword explicitly throws an exception from code, used inside method body, followed by exception object instance, and can throw only one exception at a time. The 'throws' keyword declares exceptions a method might throw, used in method signature, followed by exception class names, and can declare multiple comma-separated exceptions. Use throw for explicit exception creation and throws for declaring potential exceptions. Checked exceptions must be declared with throws or caught. Throws informs callers about exception handling requirements. Example: void method() throws IOException { throw new IOException(); }

Custom exceptions are user-defined exception classes extending Exception (checked) or RuntimeException (unchecked), providing domain-specific error handling. They improve code readability, enable specific exception handling, provide meaningful error messages, and support application-specific error categorization. To create: extend appropriate exception class, provide constructors accepting messages and causes, and optionally add fields and methods. Custom exceptions enable layered exception handling, wrapping lower-level exceptions, and providing business logic validation. Best practices include descriptive names, appropriate exception hierarchy, and meaningful error messages. Example: class InvalidUserException extends Exception { }

Errors represent serious problems in the environment or JVM that applications shouldn't try to catch, like OutOfMemoryError or StackOverflowError. They indicate unrecoverable conditions. Exceptions represent conditions that applications can catch and handle, representing problems in program logic or external resources. Exceptions are divided into checked (must handle) and unchecked (optional handling). Errors extend java.lang.Error, exceptions extend java.lang.Exception. Applications recover from exceptions but typically terminate on errors. Error examples: VirtualMachineError, AssertionError. Exception examples: IOException, SQLException, NullPointerException. Handle exceptions, let errors propagate.

The final keyword creates immutable entities. Final variables become constants whose values cannot be reassigned after initialization (though object contents can be modified). Final methods cannot be overridden by subclasses, ensuring consistent behavior. Final classes cannot be subclassed (extended), like the String class. Using final improves performance through compiler optimizations, ensures thread safety for variables, prevents accidental modification, and enforces design constraints. Constants are typically declared as 'public static final'. Final parameters prevent modification within methods.

The 'this' keyword references the current object instance within a class. It's used to differentiate instance variables from parameters or local variables when they have the same name, call other constructors in the same class using this(), pass the current object as a parameter to other methods, and return the current object from a method. The this keyword is implicit in instance method calls but becomes necessary when disambiguation is needed. It's not available in static context since static members belong to the class, not instances.

The 'super' keyword references the immediate parent class, used to access parent class members. It calls parent class constructors using super() (must be first statement in constructor), invokes parent class methods that are overridden in the child class, and accesses parent class variables hidden by child class variables with the same name. Super enables reusing parent class functionality while adding child-specific behavior. It's crucial for method overriding scenarios where you want to extend rather than completely replace parent functionality.

The Collections Framework is a unified architecture providing interfaces and classes for storing and manipulating groups of objects. Core interfaces include Collection (base interface), List (ordered, allows duplicates), Set (no duplicates), Map (key-value pairs), and Queue (FIFO operations). Key implementations are ArrayList, LinkedList, HashSet, TreeSet, HashMap, TreeMap, and PriorityQueue. The framework provides algorithms for sorting, searching, and manipulation. It promotes interoperability, reduces programming effort through reusable data structures, increases performance through optimized implementations, and provides a standard way to handle collections.

ArrayList uses a dynamic array internally, providing fast random access O(1) for get operations but slower insertions/deletions O(n) in the middle due to shifting elements. It's better for frequent access operations and is more memory-efficient. LinkedList uses a doubly-linked list structure, providing fast insertions/deletions O(1) at any position but slower random access O(n) requiring traversal. It's better when frequent insertions/deletions occur. ArrayList is generally preferred unless you need constant-time insertions/deletions or implement a queue/deque.

HashMap is non-synchronized (not thread-safe), allows one null key and multiple null values, generally faster, and is the preferred choice for single-threaded applications. Hashtable is synchronized (thread-safe), doesn't allow null keys or values, slower due to synchronization overhead, and is considered legacy. For thread-safe operations, ConcurrentHashMap is preferred over Hashtable as it provides better concurrency through segment-based locking. HashMap uses fail-fast iterators while Hashtable uses fail-safe enumerations. Modern applications typically use HashMap with external synchronization when needed.

List is an ordered collection maintaining insertion order, allowing duplicate elements, and providing positional access using indices. Implementations include ArrayList and LinkedList. Set is an unordered collection (except LinkedHashSet and TreeSet) that doesn't allow duplicate elements based on equals() and hashCode(). Set implementations include HashSet (unordered), LinkedHashSet (insertion order), and TreeSet (sorted). Use List when order matters or duplicates are needed, and Set when uniqueness is required. Set operations are typically faster for contains() checks due to hash-based implementations.

Iterator is an interface providing methods to traverse collections one element at a time. It has three main methods: hasNext() checks if more elements exist, next() returns the next element, and remove() safely removes the current element during iteration. Iterator provides a uniform way to traverse different collection types and allows element removal during iteration without ConcurrentModificationException. It's obtained using the iterator() method on collections. Iterator is fail-fast for most collections, throwing exceptions if the collection is modified during iteration except through the iterator's own remove method.

Fail-fast iterators throw ConcurrentModificationException immediately if the collection is structurally modified during iteration (except through iterator's remove method). They work on the original collection and are used by ArrayList, HashMap. Fail-safe iterators don't throw exceptions when the collection is modified; they work on a clone of the collection or use different mechanisms. Examples include iterators for ConcurrentHashMap and CopyOnWriteArrayList. Fail-fast provides immediate feedback for programming errors, while fail-safe allows concurrent modifications at the cost of not reflecting real-time changes.

Comparable is an interface with compareTo() method implemented by the class itself, defining natural ordering. The class modifying itself to become comparable. Comparator is a separate interface with compare() method, defining custom ordering without modifying the original class. One class implements Comparable once but can have multiple Comparators for different sorting criteria. Comparable is in java.lang, Comparator in java.util. Use Comparable for default/natural sorting (like String's alphabetical order). Use Comparator for custom sorting, multiple sort orders, or when you can't modify the class being sorted.

ConcurrentHashMap is a thread-safe, highly concurrent Map implementation providing better scalability than Hashtable or synchronized Map. It uses segment-based locking (pre-Java 8) or CAS operations and synchronized blocks (Java 8+), allowing multiple threads to read/write simultaneously to different segments. Key features: no locking for reads, lock-free gets, bucket-level locking for writes, thread-safe without synchronizing entire map, allows concurrent reads and writes, and maintains fail-safe iteration. It's preferred over Hashtable for concurrent applications. Size(), isEmpty() may be approximate. Default concurrency level is 16 (pre-Java 8).

ArrayList is non-synchronized (not thread-safe), faster due to no synchronization overhead, grows by 50% when capacity exceeded, modern and preferred. Vector is synchronized (thread-safe), slower due to synchronization, grows by 100% (doubles) when full, and considered legacy. ArrayList is preferred even in multi-threaded environments by using Collections.synchronizedList() or ConcurrentModifications alternatives when needed. Vector's synchronization is coarse-grained (entire method), while modern alternatives provide better concurrency. ArrayList introduced in Java 1.2, Vector in 1.0. For thread-safe lists, use CopyOnWriteArrayList for read-heavy scenarios.

HashSet uses hash table (HashMap internally), provides O(1) average time for add/remove/contains, unordered elements, allows one null element, and is fastest for basic operations. TreeSet uses Red-Black tree (TreeMap internally), provides O(log n) time for operations, maintains sorted order (natural or comparator-based), doesn't allow null, and supports range operations. Use HashSet when order doesn't matter and performance is critical. Use TreeSet when sorted order is required or range queries needed. HashSet requires good hashCode implementation. TreeSet requires Comparable implementation or Comparator. LinkedHashSet maintains insertion order.

HashMap uses hash table, provides O(1) average time for operations, unordered entries, allows one null key and multiple null values, and is preferred for most use cases. TreeMap uses Red-Black tree, provides O(log n) time, maintains sorted key order (natural or comparator), doesn't allow null keys, and supports navigable operations like firstKey(), lastKey(), subMap(). Use HashMap for best performance. Use TreeMap when sorted order or range operations needed. HashMap requires good hashCode/equals. TreeMap requires Comparable or Comparator. LinkedHashMap maintains insertion order with slightly slower performance than HashMap.

Arrays have fixed size determined at creation, can hold primitives and objects, offer better performance, use simple syntax, and provide fixed memory allocation. ArrayLists have dynamic size that grows automatically, only store objects (primitives are autoboxed), use parameterized types for type safety, provide rich methods (add, remove, contains), and have slight performance overhead. Arrays use square brackets [], ArrayLists are Collection framework members. Use arrays for fixed-size primitive data or performance-critical code. Use ArrayList for dynamic collections requiring flexibility. ArrayList internally uses array but handles resizing automatically.

Multithreading is the concurrent execution of two or more threads within a single process, enabling multiple parts of a program to run simultaneously. Each thread represents an independent path of execution sharing the process's resources but having its own stack. Multithreading improves CPU utilization, application responsiveness, and enables parallel processing. Java provides built-in support through the Thread class and Runnable interface. Common use cases include performing background operations, handling multiple user requests simultaneously, and implementing responsive GUIs. Proper synchronization is crucial to avoid race conditions.

Thread is a class that represents a thread of execution. You create threads by extending Thread class and overriding run() method, but this approach prevents extending other classes (single inheritance limitation). Runnable is an interface with a single run() method representing a task. Implementing Runnable is preferred because it allows the class to extend other classes, provides better separation of task from thread, enables thread pooling, and follows composition over inheritance principle. To execute a Runnable, pass it to a Thread constructor. Runnable is more flexible and widely used.

Thread synchronization is a mechanism controlling access to shared resources by multiple threads to prevent data inconsistency and race conditions. When multiple threads access and modify shared data simultaneously, unpredictable results occur. Synchronization ensures only one thread accesses critical sections at a time. Java provides the synchronized keyword for methods and blocks, locks from java.util.concurrent.locks package, and atomic variables. Proper synchronization prevents race conditions, ensures data integrity, maintains consistent state, but can cause performance overhead and potential deadlocks if not implemented carefully.

The synchronized keyword prevents multiple threads from simultaneously executing synchronized code blocks or methods, ensuring thread safety for shared resources. Synchronized methods lock the object instance (or class for static methods), allowing only one thread to execute any synchronized method of that object at a time. Synchronized blocks provide finer control by locking on specific objects, enabling better concurrency. Synchronization uses monitors (intrinsic locks) - every object has one. While it ensures data consistency, excessive synchronization can cause performance bottlenecks and deadlocks. Use only when necessary.

Deadlock occurs when two or more threads are blocked forever, each waiting for resources held by the others, creating a circular dependency. For example, Thread1 holds ResourceA and waits for ResourceB, while Thread2 holds ResourceB and waits for ResourceA. Prevention strategies include: avoiding nested locks, acquiring locks in a consistent order across all threads, using tryLock with timeout instead of blocking indefinitely, implementing lock timeout mechanisms, using java.util.concurrent utilities like ExecutorService, and careful design to minimize shared resources. Deadlock detection and thread dumps help diagnose issues.

The volatile keyword ensures that changes to a variable are immediately visible to all threads by preventing thread-local caching. Without volatile, threads might cache variables locally, causing visibility issues. Volatile guarantees that reads/writes go directly to main memory, not CPU caches. It's lighter than synchronization but only ensures visibility, not atomicity. Use volatile for flags that control thread behavior, simple state variables read/written by multiple threads, or ensuring happens-before relationships. However, for compound operations like increment (read-modify-write), use AtomicInteger or synchronization instead of volatile.

These Object class methods enable inter-thread communication and must be called from synchronized blocks. wait() causes the current thread to release the lock and sleep until another thread calls notify()/notifyAll() on the same object or until a timeout occurs. notify() wakes up one waiting thread randomly, while notifyAll() wakes up all waiting threads. Only one awakened thread can reacquire the lock and proceed. These methods are used for implementing producer-consumer patterns, thread coordination, and resource allocation. They must be in synchronized context to prevent race conditions.

Runnable has a run() method returning void, cannot throw checked exceptions, and is executed using Thread or ExecutorService. Callable has a call() method returning a result (generic type), can throw checked exceptions, and is only used with ExecutorService. Callable returns Future<T> representing asynchronous computation result. Use Runnable for tasks not returning results or throwing checked exceptions. Use Callable when you need return values, exception handling, or task cancellation. ExecutorService.submit() accepts both but invokeAll() and invokeAny() work only with Callable.

Future<T> represents the result of an asynchronous computation, providing methods to check completion status, wait for completion, and retrieve results. Methods include get() (blocks until result available), get(timeout, unit) (blocking with timeout), cancel() (attempt cancellation), isDone() (completion check), and isCancelled() (cancellation check). Future is returned by ExecutorService.submit() when submitting Callable or Runnable tasks. It enables asynchronous task execution with result retrieval. Limitations include blocking get(), no combining operations, and limited exception handling, addressed by CompletableFuture in Java 8.

ExecutorService is a higher-level API for managing thread pools, simplifying concurrent task execution. It decouples task submission from thread management, provides thread lifecycle management, supports task scheduling, and enables result retrieval through Future. Common implementations: Executors.newFixedThreadPool() (fixed thread count), newCachedThreadPool() (dynamic sizing), newSingleThreadExecutor() (single thread), and newScheduledThreadPool() (delayed/periodic execution). ExecutorService methods include submit(), invokeAll(), invokeAny(), and shutdown(). Benefits include resource management, task queuing, parallel execution, and avoiding manual thread creation overhead. Always shutdown executors to prevent resource leaks.

A process is an executing program with its own memory space, system resources, and independent execution context. Processes are isolated, heavyweight, and inter-process communication is expensive. A thread is a lightweight unit of execution within a process, sharing the process's memory and resources. Multiple threads exist within one process, share heap memory, have individual stacks, are lightweight, and communicate easily. Threads enable concurrency within a process, while processes enable true parallelism. Context switching between threads is faster than processes. Threads are preferred for concurrent operations within applications.

CompletableFuture is a powerful enhancement to Future introduced in Java 8, supporting non-blocking asynchronous programming and functional composition. It allows chaining operations using thenApply, thenAccept, thenCompose, combining multiple futures with thenCombine, handling exceptions with exceptionally/handle, and doesn't require blocking get() calls. CompletableFuture supports callback execution on completion, parallel execution of multiple tasks, and timeout handling. Benefits include better resource utilization, functional-style async code, easier error handling, and building complex async workflows. It's fundamental to reactive programming in Java and building responsive applications.

Fork/Join framework, introduced in Java 7, is designed for parallel processing of recursive tasks using divide-and-conquer approach. It uses a work-stealing algorithm where idle threads steal tasks from busy threads' queues. Core components include ForkJoinPool (special thread pool), ForkJoinTask (abstract task), RecursiveTask (returns result), and RecursiveAction (no result). The fork() method splits tasks asynchronously, join() waits for completion. Fork/Join is optimal for CPU-intensive tasks that can be broken into smaller subtasks, like parallel sorting, searching, and matrix operations. It maximizes CPU utilization through intelligent task distribution.

CountDownLatch is a synchronization utility allowing one or more threads to wait until a set of operations in other threads completes. It's initialized with a count, threads call await() to wait, and other threads call countDown() to decrement the count. When count reaches zero, all waiting threads proceed. CountDownLatch cannot be reused (count doesn't reset). Use cases include waiting for multiple services to start, coordinating parallel task completion, and implementing barriers. It's useful in testing for ensuring all threads complete before assertions. For reusable counters, use CyclicBarrier.

CyclicBarrier is a synchronization mechanism allowing a set of threads to wait for each other to reach a common barrier point. Unlike CountDownLatch, CyclicBarrier is reusable. Threads call await(), blocking until all threads reach the barrier. When all arrive, an optional barrier action executes, then threads are released and barrier resets. CyclicBarrier is useful for parallel algorithms requiring synchronization at multiple phases, like parallel matrix multiplication, iterative simulations, or multi-phase processing. The barrier count represents thread count that must arrive. It supports timeout and can be broken on exceptions.

Semaphore maintains a set of permits controlling thread access to shared resources. Threads acquire permits using acquire() (blocking if unavailable) and release them using release(). Semaphore limits concurrent access to resources, unlike locks which provide exclusive access. It's useful for resource pools (like database connections), implementing bounded buffers, and controlling concurrency levels. Fair semaphores grant permits in FIFO order. Binary semaphore (1 permit) works like a mutex. Semaphores don't have ownership concept - any thread can release permits. They're versatile for implementing custom synchronization patterns and rate limiting.

ThreadLocal provides thread-local variables where each thread accessing the variable has its own independently initialized copy. It isolates data per thread, preventing sharing and synchronization issues. ThreadLocal is useful for storing user context, database connections per thread, SimpleDateFormat (not thread-safe) instances, and request/transaction context. Methods include get(), set(), remove(), and initialValue(). Important: always remove() thread-local variables in thread pools to prevent memory leaks, as threads are reused. ThreadLocal doesn't solve sharing problems; it creates isolated copies. Use sparingly as it can hide dependencies and complicate testing.

Atomic variables from java.util.concurrent.atomic package provide lock-free, thread-safe operations on single variables using CAS (Compare-And-Swap) hardware primitives. Classes include AtomicInteger, AtomicLong, AtomicBoolean, and AtomicReference. They provide atomic methods like get(), set(), compareAndSet(), incrementAndGet(), and getAndIncrement(). Atomic variables are faster than synchronization for simple operations, avoid blocking, prevent race conditions, and are suitable for counters, flags, and reference updates. They use non-blocking algorithms, ensuring progress and avoiding deadlocks. More efficient than synchronized blocks for uncontended access but may perform worse under high contention.

Generics enable types (classes, interfaces) to be parameters when defining classes, interfaces, and methods, providing compile-time type safety. They eliminate explicit type casting, catch type errors at compile-time rather than runtime, and enable writing reusable code for different data types. For example, ArrayList<String> ensures only strings are stored. Generics use type parameters like <T>, <E>, <K,V> and support bounded types, wildcards, and generic methods. Benefits include stronger type checks, elimination of casts, and enabling generic algorithms. Type erasure removes generic type information at runtime for backward compatibility.

Serialization converts an object's state into a byte stream for storage or transmission, while deserialization reconstructs the object from the byte stream. Classes must implement the Serializable interface (marker interface with no methods). The serialVersionUID helps maintain version compatibility across different class versions. Transient fields are excluded from serialization. Serialization is used for persistent storage, network transmission, deep copying, caching, and distributed computing. Common implementations use ObjectOutputStream for serialization and ObjectInputStream for deserialization. Security concerns include potential code injection, so validate deserialized objects carefully.

The transient keyword marks instance variables that should be excluded from serialization. When an object is serialized, transient fields are ignored, and during deserialization, they're initialized to default values (null for objects, 0 for numbers, false for boolean). This is useful for excluding sensitive data like passwords, derived fields that can be recalculated, temporary caching variables, or fields referencing non-serializable objects. Transient helps control serialization, reduces serialized object size, enhances security by preventing sensitive data persistence, and maintains class compatibility. Static fields aren't serialized regardless.

Reflection is the ability to inspect and manipulate classes, interfaces, fields, and methods at runtime without knowing their names at compile-time. It's provided by java.lang.reflect package. Reflection enables dynamic class loading, method invocation, field access modification, annotation processing, and creating objects without using constructors. Frameworks like Spring, Hibernate, and JUnit heavily use reflection for dependency injection, ORM mapping, and test discovery. However, reflection has performance overhead, breaks encapsulation, requires security permissions, and can bypass compile-time type checking. Use sparingly and cache reflected objects.

Annotations are metadata tags providing information about code to compiler, tools, or runtime. They don't directly affect program logic but provide instructions for processing. Built-in annotations include @Override, @Deprecated, @SuppressWarnings, @FunctionalInterface. Custom annotations use @interface keyword. Meta-annotations like @Retention (lifecycle), @Target (applicable elements), @Inherited, and @Documented control annotation behavior. Annotations enable declarative programming, framework configuration, code generation, validation, and documentation. Reflection retrieves annotation information at runtime. Used extensively in frameworks like Spring (@Autowired), JPA (@Entity), and testing (JUnit's @Test).

SPI is a mechanism enabling frameworks to discover and load implementations dynamically without hard-coding dependencies. It's used for extending functionality via plugins. Implementation involves: defining service interface, providing implementation with META-INF/services configuration file, and loading using ServiceLoader. Examples include JDBC drivers, logging frameworks, and Java's CharSet providers. SPI enables loose coupling, extensibility without recompilation, and plugin architectures. Configuration file in META-INF/services contains implementation class names. ServiceLoader.load() discovers and instantiates implementations. SPI supports modularity and follows Dependency Inversion principle.

Lambda expressions are anonymous functions providing a concise way to implement functional interfaces (interfaces with single abstract method). They enable functional programming style, making code more readable and maintainable. Syntax: (parameters) -> expression or (parameters) -> { statements }. Lambdas eliminate boilerplate code, enable passing behavior as parameters, work seamlessly with Stream API, and support parallel processing. Common use cases include collection operations, event handlers, and callbacks. Lambdas can access effectively final variables from enclosing scope, creating closures. They're compiled to invokedynamic instructions for performance.

Functional interfaces contain exactly one abstract method and can have multiple default or static methods. They're marked with @FunctionalInterface annotation (optional but recommended) which causes compiler error if multiple abstract methods exist. Functional interfaces enable lambda expressions and method references. Java provides built-in functional interfaces in java.util.function package: Predicate<T> (boolean test), Consumer<T> (void operation), Function<T,R> (transformation), Supplier<T> (value provider), and BiFunction<T,U,R> (two-argument function). Custom functional interfaces can be created for specific use cases. They're fundamental to functional programming in Java.

Stream API provides a functional approach to processing collections through a sequence of operations. Streams support internal iteration, lazy evaluation, and parallel processing. Operations are divided into intermediate (filter, map, sorted - return streams) and terminal (forEach, collect, reduce - produce results). Streams don't store data, they operate on source data structures. Benefits include concise code, improved readability, easy parallelization using parallelStream(), optimized operations through lazy evaluation, and support for functional programming. Streams are consumed after terminal operation and cannot be reused. Common operations include filtering, mapping, reducing, and collecting.

Optional<T> is a container object representing presence or absence of a value, designed to prevent NullPointerException. It forces explicit handling of null cases, making code more robust and readable. Optional provides methods like isPresent(), get(), orElse(), orElseGet(), orElseThrow(), ifPresent(), map(), and flatMap(). Use Optional as return types for methods that might not return a value, not as method parameters or fields. Benefits include explicit null handling, functional-style operations, reduced null checks, and preventing null-related bugs. Avoid using get() without isPresent() check.

Default methods, introduced in Java 8, are methods in interfaces with implementations using the 'default' keyword. They allow adding new methods to interfaces without breaking existing implementations, solving the interface evolution problem. Implementing classes can override default methods or use the interface's implementation. If a class implements multiple interfaces with same default method, it must override to resolve ambiguity. Default methods enable functional programming features in Collection API (like stream()) while maintaining backward compatibility. They blur the line between interfaces and abstract classes but serve different purposes.

Method references are shorthand syntax for lambda expressions calling a single method, making code more readable. Four types exist: static method reference (ClassName::staticMethod), instance method reference of particular object (object::instanceMethod), instance method reference of arbitrary object (ClassName::instanceMethod), and constructor reference (ClassName::new). Method references are used with functional interfaces where lambda would simply call an existing method. They improve code clarity, reduce verbosity, and work seamlessly with Stream API. Examples: list.forEach(System.out::println) instead of list.forEach(x -> System.out.println(x)).

Singleton ensures a class has only one instance and provides global access point to it. Implementation involves private constructor preventing external instantiation, private static instance variable, and public static getInstance() method. Thread-safe implementations include: eager initialization (instance created at class loading), lazy initialization with double-checked locking using volatile, and enum (best practice, inherently thread-safe). Singletons are used for logging, configuration management, database connections, and caching. However, they can make testing difficult, create tight coupling, and potentially cause memory leaks in web applications if not implemented carefully.

Factory pattern provides an interface for creating objects without specifying exact classes, promoting loose coupling. The factory method defines an interface for object creation, letting subclasses decide which class to instantiate. Benefits include hiding creation logic, promoting code reusability, easy maintenance when adding new types, and supporting dependency injection. Factory pattern separates object construction from usage, enables centralized configuration, and follows Single Responsibility and Open/Closed principles. Common implementations include Simple Factory, Factory Method, and Abstract Factory patterns. Used extensively in frameworks like Spring for bean creation.

Dependency Injection (DI) is a design pattern where objects receive dependencies from external sources rather than creating them. It inverts control flow, promoting loose coupling, testability, and maintainability. Three types exist: constructor injection (dependencies passed through constructor - recommended), setter injection (through setter methods), and field injection (directly into fields - not recommended). DI frameworks like Spring manage object lifecycles and dependency wiring. Benefits include easier unit testing through mock injection, flexible configuration, reusable components, and separation of concerns. DI enables Inversion of Control (IoC) principle.

JDBC (Java Database Connectivity) is an API enabling Java applications to interact with databases through SQL execution. Core components include: DriverManager (manages database drivers), Driver (interface for database-specific drivers), Connection (database session), Statement (executes SQL queries), PreparedStatement (precompiled SQL with parameters), CallableStatement (stored procedures), and ResultSet (query results). JDBC provides database-independent code, supporting multiple databases through different drivers. Four driver types exist: Type-1 (JDBC-ODBC bridge), Type-2 (Native-API), Type-3 (Network Protocol), and Type-4 (Pure Java - preferred). JDBC enables enterprise application database integration.

Statement executes simple SQL queries without parameters, compiling SQL each execution, slower for repeated queries, and vulnerable to SQL injection. PreparedStatement executes precompiled SQL with parameters, uses placeholders (?), compiled once and reused, faster for repeated execution, and prevents SQL injection through parameter binding. PreparedStatement supports batch processing, improves performance through caching, provides type safety, and is preferred for queries with user input. Use Statement only for simple, one-time queries without parameters. PreparedStatement is the standard choice for production code.

Connection pooling maintains a pool of database connections that can be reused, avoiding expensive connection creation overhead for each request. When an application requests a connection, it's borrowed from the pool; after use, it's returned rather than closed. Benefits include improved performance (reduced connection establishment time), resource efficiency (controlled connection count), scalability (handling more concurrent users), and reduced database load. Popular implementations: HikariCP, Apache DBCP, C3P0. Configuration includes pool size, timeout, validation queries, and idle timeout. Connection pooling is essential for high-performance database applications and prevents connection exhaustion.

Composition over inheritance is a design principle favoring object composition (HAS-A relationship) over class inheritance (IS-A relationship) for code reuse. Composition provides greater flexibility, easier testing through dependency injection, avoids fragile base class problem, enables runtime behavior changes, and prevents tight coupling. Instead of extending classes, objects contain references to other objects and delegate functionality. Benefits include better encapsulation, easier refactoring, multiple composition sources (vs single inheritance), and avoiding inheritance hierarchies. Example: Car HAS-A Engine rather than Car IS-A Engine. Composition is preferred in modern design patterns and frameworks.

SOLID is an acronym for five object-oriented design principles: Single Responsibility Principle (class should have one reason to change), Open/Closed Principle (open for extension, closed for modification), Liskov Substitution Principle (subtypes must be substitutable for base types), Interface Segregation Principle (clients shouldn't depend on unused interfaces), and Dependency Inversion Principle (depend on abstractions, not concretions). These principles improve code maintainability, testability, flexibility, and reduce coupling. They guide creating robust, scalable systems and are fundamental to modern software design. Understanding SOLID principles is essential for writing professional Java code.

Varargs (variable arguments) allow methods to accept zero or more arguments of specified type using ellipsis (...) syntax. The varargs parameter must be last in parameter list, only one varargs allowed per method, and is treated as an array internally. Example: void method(String... args). Varargs eliminate array creation boilerplate, improve method call readability, and enable flexible APIs. Common in String.format(), Collections.addAll(). Calling with no arguments passes empty array. Can pass array directly. Varargs work with primitives and objects. Useful for utility methods accepting variable inputs.

The instanceof operator tests whether an object is an instance of a specific class, subclass, or implements an interface, returning boolean. It checks the complete inheritance hierarchy. Returns false for null. Syntax: object instanceof Type. Useful before type casting to prevent ClassCastException, in polymorphic code to determine actual object type, and implementing type-specific logic. However, excessive instanceof indicates poor design; prefer polymorphism. Pattern matching for instanceof (Java 16+) combines test and cast: if (obj instanceof String s). Common in frameworks for reflection-based operations and custom serialization.

Static import allows importing static members (fields and methods) from a class, enabling direct use without class name qualification. Syntax: import static packageName.ClassName.staticMember or import static packageName.ClassName.*. Example: import static java.lang.Math.* allows sqrt(4) instead of Math.sqrt(4). Benefits include reduced verbosity for frequently used static members, improved readability for utility methods, and cleaner code. However, overuse reduces code clarity, causes naming conflicts, and makes code harder to understand. Use judiciously for well-known constants like Math.PI or enum values. Avoid wildcard static imports.

Scanner parses primitive types and strings using regular expressions, provides convenient nextInt(), nextDouble() methods, slower due to parsing overhead, synchronized (thread-safe), and suitable for parsing formatted input. BufferedReader reads character streams efficiently using buffering, returns only strings via readLine(), faster for large inputs, not synchronized, and better for reading plain text files. Scanner is easier for parsing diverse input types. BufferedReader is faster for reading large text files. For console input, Scanner is convenient. For file reading, BufferedReader is preferred. Both implement AutoCloseable for try-with-resources.

NIO (New I/O), introduced in Java 4 and enhanced in Java 7 (NIO.2), provides non-blocking I/O operations for better scalability. Key components: Channels (bidirectional data connections), Buffers (data containers), Selectors (multiplexing for multiple channels with single thread). NIO supports non-blocking operations, enabling one thread to handle multiple connections efficiently. Features include memory-mapped files, file locking, character encoding/decoding. NIO.2 adds Path, Files, WatchService for file operations. Benefits include better performance for high-concurrency scenarios, scalability, and efficient resource usage. Suitable for servers handling many connections. More complex than traditional I/O.

Java Platform Module System (JPMS) introduced in Java 9 provides better encapsulation and dependency management. Modules are defined in module-info.java with exports (what's accessible), requires (dependencies), and opens (reflection access). Benefits include strong encapsulation (packages hidden by default), reliable configuration (missing dependencies detected at startup), improved security, reduced JRE size via jlink, and better application structure. Modules replace classpath with module path. Challenges include migration complexity for legacy code and library support. Modules enable creation of custom runtime images with only required modules.

Records, introduced in Java 14 (finalized in Java 16), are special classes for immutable data carriers, eliminating boilerplate code. Records automatically generate constructor, getters (accessor methods), equals(), hashCode(), and toString(). Syntax: record Person(String name, int age) { }. Records are implicitly final, all fields are private final, cannot extend other classes (but can implement interfaces), and support compact constructors for validation. Use records for DTOs, value objects, return types from methods, and API responses. They promote immutability, reduce code verbosity, and make intent clear. Records can have static methods and custom instance methods.