No, `String` is not the only immutable class in Java.

There are other immutable

classes as well. Here are some common examples of immutable classes in Java:

### 1. **`String`**:
- The most well-known immutable class. Once a `String` object is created, its value
cannot be changed.

### 2. **Wrapper Classes**:

- All primitive wrapper classes in Java, such as:
- `Integer`
- `Double`
- `Float`
- `Long`
- `Byte`
- `Short`
- `Character`
- `Boolean`
- These classes are immutable. For example, if you create an `Integer` object, you
cannot change its value after creation. Any "modification" creates a new object.

### 3. **`BigInteger` and `BigDecimal`**:

- These classes represent arbitrary-precision numbers and are immutable. Operations
on `BigInteger` and `BigDecimal` return new objects instead of modifying the
existing ones.

### 4. **`java.time` Package Classes**:

- The classes in the `java.time` package introduced in Java 8 are immutable:
- `LocalDate`
- `LocalTime`
- `LocalDateTime`
- `ZonedDateTime`
- `Instant`
- `Duration`
- `Period`
- These classes do not have methods that modify their state; any modification
produces a new instance.

### 5. **Custom Immutable Classes**:

- You can create your own immutable classes by following these practices:
- Mark the class as `final` to prevent inheritance.
- Declare all fields as `private` and `final`.
- Do not provide "setter" methods.
- Ensure that mutable objects referenced by fields are either:
- Made immutable themselves, or
- Cloned when accessed or modified.

### **Why Immutability Matters**:

- **Thread-safety**: Immutable objects are inherently thread-safe as their state
cannot be changed after creation.
- **Caching**: Immutable objects can be safely cached and reused without the risk
of their state changing.
- **Simplicity**: They are simpler to reason about because their state is
consistent after creation.

In conclusion, while `String` is a prominent example, Java has several other built-
in immutable classes, and it's possible to create custom immutable classes.
===================================
`BigInteger` and `BigDecimal` are Java classes used for handling very large or very
precise numerical values that go beyond the limits of primitive data types like
`int`, `long`, `float`, and `double`. Here’s how, where, and when to use them:

### 1. **`BigInteger`**:
- **How to Use**:
- Create `BigInteger` objects using constructors or static factory methods.
- Perform operations using methods provided by the `BigInteger` class (e.g.,
`add()`, `subtract()`, `multiply()`, `divide()`).
- **When to Use**:
- When dealing with integers larger than `Long.MAX_VALUE` (which is
`9,223,372,036,854,775,807`).
- When precision must be maintained for very large integer calculations without
any overflow.
- **Example**:
```java
import java.math.BigInteger;

public class BigIntegerExample {

public static void main(String[] args) {
BigInteger num1 = new BigInteger("123456789012345678901234567890");
BigInteger num2 = new BigInteger("987654321098765432109876543210");

BigInteger sum = num1.add(num2);

BigInteger product = num1.multiply(num2);

System.out.println("Sum: " + sum);

System.out.println("Product: " + product);
}
}
```
- **Where to Use**:
- Cryptographic algorithms, factorials, combinations, and any computation
requiring very large integers.

### 2. **`BigDecimal`**:
- **How to Use**:
- Create `BigDecimal` objects using constructors or `BigDecimal.valueOf()` to
avoid precision issues.
- Perform operations using methods like `add()`, `subtract()`, `multiply()`,
`divide()` and control the scale (number of decimal places).
- **When to Use**:
- When precision must be maintained for decimal numbers, such as in financial and
scientific calculations.
- When floating-point precision (`float` and `double`) is inadequate due to
rounding errors.
- **Example**:
```java
import java.math.BigDecimal;
import java.math.RoundingMode;

public class BigDecimalExample {

public static void main(String[] args) {
BigDecimal num1 = new BigDecimal("12345.6789");
BigDecimal num2 = new BigDecimal("0.0001");

BigDecimal sum = num1.add(num2);

BigDecimal division = num1.divide(num2, 10, RoundingMode.HALF_UP); //
Specify scale and rounding mode

System.out.println("Sum: " + sum);

 System.out.println("Division (with scale): " + division);
}
}
```
- **Where to Use**:
- **Financial applications**: To avoid rounding issues that could result in
significant financial inaccuracies.
- **Scientific calculations**: Where a high degree of precision is required
(e.g., calculating pi or mathematical constants).
- **Any calculation needing absolute precision**, such as tax calculations or
currency conversion.

### **Key Points to Consider**:

- **Immutability**: Both `BigInteger` and `BigDecimal` are immutable, meaning that
any modification produces a new instance. This ensures thread safety.
- **Performance**: They are slower than primitive types (`int`, `long`, `float`,
`double`) due to their complex internal structures and methods. Use them only when
precision is crucial.
- **Constructors**: Avoid using `new BigDecimal(double)` because it can lead to
precision issues. Prefer `new BigDecimal("123.456")` or
`BigDecimal.valueOf(123.456)` for accurate results.

### **Choosing Between Them**:

- Use **`BigInteger`** for calculations involving very large whole numbers.
- Use **`BigDecimal`** when you need accurate decimal representation, especially
for financial data or where precision matters.

### **Common Use Cases**:

- **`BigInteger`**: Calculating factorials, cryptographic keys, or mathematical
operations with very large integers.
- **`BigDecimal`**: Financial software for currency, accounting systems, or any
application requiring precise decimal arithmetic.

Both classes are part of the `java.math` package, making them accessible and easy
to integrate into projects that require precise arithmetic.
=============================
No, member variables (fields) in a parent class **cannot be overridden** in a child
class. In Java, **only methods** can be overridden. However, you can **hide**
member variables by declaring a field with the same name in the subclass, but this
is not the same as overriding.

### Explanation:
- **Method Overriding**: When a subclass provides a specific implementation for a
method already defined in its parent class. The overridden method in the child
class should have the same method signature (name, return type, and parameters).
- **Field Hiding**: When a subclass defines a field with the same name as one in
the parent class, the field in the parent class is hidden in the subclass. This
means that references to the field depend on whether they are accessed through a
reference to the parent class or the subclass.

### Example of Field Hiding:

```java
class Parent {
public String name = "Parent";

public void showName() {

System.out.println("Name: " + name);
}
}
class Child extends Parent {
public String name = "Child"; // This hides the 'name' field in the Parent
class

@Override
public void showName() {
System.out.println("Name: " + name);
}
}

public class Main {

public static void main(String[] args) {
Parent parent = new Parent();
System.out.println("Parent name: " + parent.name); // Outputs "Parent"

Child child = new Child();

System.out.println("Child name: " + child.name); // Outputs "Child"

Parent parentRefToChild = new Child();

System.out.println("Parent reference to child name: " +
parentRefToChild.name); // Outputs "Parent"

// Demonstrating overridden method behavior

parent.showName(); // Outputs "Name: Parent"
child.showName(); // Outputs "Name: Child"
parentRefToChild.showName(); // Outputs "Name: Child" (method overriding)
}
}
```

### Key Points:

- **Field Access**: Field access is determined by the **type of the reference**,
not the actual object type. This is why `parentRefToChild.name` prints `"Parent"`
even though it refers to a `Child` object.
- **Method Access**: Method access (for overridden methods) is determined by the
**actual object type**, which is why `parentRefToChild.showName()` calls the
`Child` class’s `showName()` method.

### Conclusion:
- You **cannot override** fields; you can only **hide** them. This behavior can
sometimes be confusing and is generally discouraged as it can lead to unexpected
results.
========================================
Creating shallow and deep copies of an instance in a class can be achieved using
different approaches in Java. Here's how you can create them:

### 1. **Shallow Copy**

A shallow copy of an object is a new object that is a copy of the original object,
but only the top-level properties are copied. If the object contains references to
other objects, only the references are copied (not the actual objects).

**Example of Shallow Copy:**

```java
class Person implements Cloneable {
String name;
Address address; // Address is a reference type

public Person(String name, Address address) {

 this.name = name;
this.address = address;
}

// Override the clone() method to create a shallow copy

@Override
protected Object clone() throws CloneNotSupportedException {
return super.clone();
}
}

class Address {
String city;

public Address(String city) {

this.city = city;
}
}

public class ShallowCopyExample {

public static void main(String[] args) throws CloneNotSupportedException {
Address address = new Address("New York");
Person person1 = new Person("John", address);

// Create a shallow copy

Person person2 = (Person) person1.clone();

// Modify the address in person2

person2.address.city = "Los Angeles";

// Both person1 and person2 will have the updated city name because it's a
shallow copy
System.out.println(person1.name + " lives in " + person1.address.city); //
Output: John lives in Los Angeles
System.out.println(person2.name + " lives in " + person2.address.city); //
Output: John lives in Los Angeles
}
}
```

### Explanation:
- In a **shallow copy**, the `clone()` method provided by `Object` is used. The
object itself is cloned, but the references inside the object point to the same
instances as in the original object.

### 2. **Deep Copy**

A deep copy creates a new object and recursively copies all the objects referenced
by the original object. This ensures that changes to the copied object do not
affect the original object.

**Example of Deep Copy:**

```java
class Person implements Cloneable {
String name;
Address address;

public Person(String name, Address address) {

this.name = name;
this.address = address;
 }

// Override the clone() method to create a deep copy

@Override
protected Object clone() throws CloneNotSupportedException {
// Perform a shallow copy first
Person clonedPerson = (Person) super.clone();
// Manually copy the mutable reference type field
clonedPerson.address = new Address(this.address.city);
return clonedPerson;
}
}

class Address {
String city;

public Address(String city) {

this.city = city;
}
}

public class DeepCopyExample {

public static void main(String[] args) throws CloneNotSupportedException {
Address address = new Address("New York");
Person person1 = new Person("John", address);

// Create a deep copy

Person person2 = (Person) person1.clone();

// Modify the address in person2

person2.address.city = "Los Angeles";

// person1's address will not be affected

System.out.println(person1.name + " lives in " + person1.address.city); //
Output: John lives in New York
System.out.println(person2.name + " lives in " + person2.address.city); //
Output: John lives in Los Angeles
}
}
```

### Explanation:
- In a **deep copy**, you need to manually copy objects that are referenced within
the object, ensuring that separate instances are created for nested objects.

### Alternatives to Manual Cloning:

1. **Serialization**:
- You can serialize and then deserialize an object to create a deep copy.
```java
import java.io.*;

public static <T> T deepCopy(T object) {

try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(object);
oos.flush();
ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
 return (T) ois.readObject();
} catch (IOException | ClassNotFoundException e) {
throw new RuntimeException("Error during deep copy", e);
}
}
```

2. **Third-Party Libraries**:
- Libraries like **Apache Commons Lang** and **Gson** can also be used to
perform deep copying with less code.

### When to Use Each:

- **Shallow Copy**: Use when the object has only primitive fields or if you don't
mind the referenced objects being shared.
- **Deep Copy**: Use when the object has complex references, and you need full
independence between the original and copied objects.
===============================
### 1. **Marker Interfaces**
A **marker interface** is an interface that does not have any methods or fields and
serves a very specific purpose: it acts as a "tag" or "marker" to indicate that a
class possesses a certain property or should be treated in a certain way. Examples
in Java include:

- **`Cloneable`**: Indicates that a class allows its instances to be cloned using

the `clone()` method. If a class does not implement `Cloneable`, calling `clone()`
on an instance will throw a `CloneNotSupportedException`.
- **`Serializable`**: Marks a class as being serializable, which allows instances
of the class to be converted into a byte stream for storage or transmission and
then deserialized back into an object.
- **`Remote`** (in RMI): Marks a class as being capable of remote method
invocation.

#### Use of Marker Interfaces:

- **Signaling Metadata**: Marker interfaces convey metadata to the Java compiler or
JVM to indicate how an object should behave or be treated.
- **Type Safety**: They provide type safety by using `instanceof` checks to ensure
that only marked objects are processed in certain ways.
- **Design Intent**: They make the design intention clear. For instance,
implementing `Serializable` shows that a class can be serialized, while `Cloneable`
indicates that instances can be cloned.

**Example**:
```java
public class MyClass implements Serializable {
// This class can now be serialized
}
```

### 2. **Functional Interfaces**

A **functional interface** is an interface with exactly **one abstract method**,
but it can have multiple default or static methods. Functional interfaces are used
as the basis for **lambda expressions** and **method references** in Java. They
enable functional programming within Java, starting with Java 8.

#### Examples of Functional Interfaces:

- **`Runnable`**: Contains the single method `void run()`.
- **`Callable<V>`**: Contains the single method `V call() throws Exception`.
- **`Comparable<T>`**: Contains the single method `int compareTo(T o)`.
- **`Predicate<T>`**, **`Function<T, R>`**, **`Consumer<T>`**: These are provided
in `java.util.function` package for common operations.

#### Use of Functional Interfaces:

- **Lambda Expressions**: Functional interfaces allow you to implement the single
abstract method using concise lambda expressions. This makes the code more readable
and expressive.
- **Method References**: Functional interfaces enable method references, allowing
you to pass references to existing methods instead of writing lambdas.
- **Higher-Order Functions**: Functional interfaces facilitate higher-order
functions (functions that take other functions as parameters or return functions).

**Example**:
```java
@FunctionalInterface
interface MyFunctionalInterface {
void execute(); // Only one abstract method allowed
}

public class Main {

public static void main(String[] args) {
// Using a lambda expression to implement the method
MyFunctionalInterface func = () -> System.out.println("Executing!");
func.execute(); // Output: Executing!
}
}
```

### Annotations and Functional Interfaces:

- **`@FunctionalInterface` Annotation**: This annotation is used to indicate that
an interface is intended to be a functional interface. It is not mandatory but is a
good practice as it enforces the single abstract method rule at compile time.

**Example with `@FunctionalInterface`**:

```java
@FunctionalInterface
interface Calculator {
int calculate(int x, int y);
}

public class Main {

public static void main(String[] args) {
Calculator add = (a, b) -> a + b;
System.out.println("Sum: " + add.calculate(5, 3)); // Output: Sum: 8
}
}
```

### Key Differences Between Marker and Functional Interfaces:

1. **Purpose**:
- **Marker Interface**: Used to signal or mark a class to convey metadata
without defining any behavior.
- **Functional Interface**: Used to define a contract with one abstract method,
enabling lambda expressions and functional programming.

2. **Method Requirements**:
- **Marker Interface**: Has no methods at all.
- **Functional Interface**: Must have exactly one abstract method.

3. **Typical Use Cases**:

 - **Marker Interface**: To indicate capabilities (e.g., `Serializable` for
serialization).
- **Functional Interface**: To represent functions or operations that can be
passed around and executed (e.g., `Runnable` for threads).

Both marker and functional interfaces play essential roles in Java programming.
Marker interfaces help in tagging classes for special treatment, while functional
interfaces enable more expressive and concise code using lambdas and method
references.
==================================
In Spring Boot (and Spring Framework in general), `@Configuration`, `@Component`,
and `@Service` are annotations used to define and manage beans and components
within the Spring container. Although they all play roles in defining beans, they
have specific uses and differences. Here’s a detailed look at each:

### 1. **`@Component` Annotation**

- **General Purpose**: `@Component` is a generic stereotype annotation used to mark
a class as a Spring-managed bean.
- **Use Case**: It is used when you want to create a basic bean that is detected by
component scanning. It tells Spring that this class should be managed as a bean and
included in the application context.
- **Example**:
```java
@Component
public class MyComponent {
public void doSomething() {
System.out.println("Doing something...");
}
}
```

- **Scanning**: Classes annotated with `@Component` are automatically discovered by

Spring during component scanning if they are within a package specified by
`@ComponentScan` or in the base package.

### 2. **`@Service` Annotation**

- **Specialized `@Component`**: `@Service` is a specialization of `@Component` with
more specific semantics. It is used to indicate that a class is a service component
in the service layer of the application.
- **Semantic Clarity**: Using `@Service` helps clarify the intent of the class,
making it clear that the class is part of the service layer and contains business
logic.
- **Use Case**: It’s often used in service classes where business logic is
implemented.
- **Example**:
```java
@Service
public class MyService {
public String process() {
return "Processing data...";
}
}
```

- **Difference from `@Component`**: The primary difference is semantic; `@Service`

makes the code more readable and aligns with best practices by indicating that the
class is a service.

### 3. **`@Configuration` Annotation**

- **Configuration Class**: `@Configuration` is used to indicate that a class
declares one or more `@Bean` methods and may be processed by the Spring container
to generate bean definitions and service requests for those beans at runtime.
- **Purpose**: This annotation is typically used for configuration classes, where
you define beans and their dependencies explicitly through Java code instead of XML
configuration.
- **Example**:
```java
@Configuration
public class AppConfig {

@Bean
public MyService myService() {
return new MyService();
}
}
```

- **Proxy Creation**: Classes annotated with `@Configuration` are automatically

subclassed at runtime by Spring to create a proxy that ensures any `@Bean` methods
are managed correctly.
- **Difference from `@Component` and `@Service`**: While `@Component` and
`@Service` are used to mark beans that represent parts of an application (e.g.,
services, components), `@Configuration` is used specifically to define and
configure beans and is typically not used to define regular components or services.

### Key Differences Between Them:

1. **Purpose**:
- **`@Component`**: A generic stereotype for any Spring-managed component.
- **`@Service`**: A specialized annotation that indicates the class holds
business logic (service layer).
- **`@Configuration`**: Used to define and configure beans in the application
context.

2. **Semantics**:
- **`@Service`** adds more meaning to the code, indicating the class provides a
service.
- **`@Component`** can be used anywhere, but `@Service` and `@Configuration`
suggest more specific roles.

3. **Component Scanning**:
- All three annotations are discovered during component scanning if configured
correctly. However, `@Configuration` is used to explicitly define bean methods.

### When to Use Which:

- **`@Component`**: Use it for generic components like utility classes or data-
access classes.
- **`@Service`**: Use it for classes that provide business logic or service-related
functionality to clarify that they belong to the service layer.
- **`@Configuration`**: Use it for configuration classes where you need to define
beans explicitly with `@Bean` methods for more control over bean creation and
dependencies.

### Example of Using All Three:

```java
@Configuration
public class AppConfig {
@Bean
public MyService myService() {
 return new MyService();
}
}

@Service
public class MyService {
public void performService() {
System.out.println("Service logic executed.");
}
}

@Component
public class MyComponent {
public void doWork() {
System.out.println("Component work done.");
}
}
```

In this example:
- `AppConfig` is a configuration class defining beans.
- `MyService` is marked with `@Service`, showing it contains business logic.
- `MyComponent` is marked with `@Component` for general component usage.
===========================
`@RestController` is an annotation in Spring Boot (and Spring Framework) that is
used to create RESTful web services. It combines the functionality of `@Controller`
and `@ResponseBody` annotations to simplify the creation of RESTful APIs.

### Details and Purpose:

- **Combination of Annotations**: `@RestController` is effectively a shortcut for
`@Controller` with `@ResponseBody` included. This means that every method in a
class annotated with `@RestController` automatically serializes the return object
into JSON or XML format and writes it directly to the HTTP response body.
- **Simplifies Code**: It eliminates the need to annotate each method with
`@ResponseBody`.

### Key Features:

1. **JSON/XML Response**: By default, methods return data in JSON format (if
configured in the application) or can support XML if additional configuration is
provided.
2. **RESTful Services**: It is used specifically for RESTful web services to handle
HTTP requests and respond with data instead of rendering views (e.g., JSP or
Thymeleaf).
3. **Automatic Serialization**: The method return values are automatically
serialized to JSON or XML using the configured `HttpMessageConverters`.

### Example Usage:

```java
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api")
public class MyRestController {

@GetMapping("/hello")
public String sayHello() {
return "Hello, World!";
 }

@GetMapping("/data")
public MyData getData() {
return new MyData("Sample", 123);
}
}

class MyData {
private String name;
private int value;

public MyData(String name, int value) {

this.name = name;
this.value = value;
}

// Getters and setters (or use lombok for brevity)

}
```

### Explanation of the Example:

- **`@RestController`**: The `MyRestController` class is annotated with
`@RestController`, making it a RESTful controller that handles web requests and
returns responses.
- **`@GetMapping("/hello")`**: This endpoint returns a simple `String`, which is
automatically sent as plain text.
- **`@GetMapping("/data")`**: This endpoint returns a `MyData` object, which is
serialized to JSON automatically.

### When to Use `@RestController`:

- **RESTful APIs**: Use `@RestController` when building RESTful web services that
provide data as a response in JSON or XML format.
- **Simplification**: If you are only dealing with responses that do not need a
view rendering, `@RestController` simplifies the code by avoiding repetitive
`@ResponseBody` annotations.

### Difference Between `@Controller` and `@RestController`:

- **`@Controller`**: Typically used for rendering views. Methods in a
`@Controller`-annotated class return a `ModelAndView` or a `String` representing a
view name, and data needs to be manually annotated with `@ResponseBody` to be sent
as JSON or XML.
- **`@RestController`**: Automatically returns data serialized to JSON or XML. It
is used specifically for building RESTful web services where the response body is
the main focus.

In conclusion, `@RestController` is a powerful and convenient annotation that

streamlines the creation of RESTful web services by combining the functionality of
`@Controller` and `@ResponseBody`.
=========================
In Spring Framework, beans are objects that are managed by the Spring IoC
(Inversion of Control) container. The process of creating and managing these beans
is a fundamental aspect of the Spring Framework’s capabilities. Here's a detailed
look at how and when beans are created in Spring:

### 1. **Bean Creation Process**

The process of bean creation in Spring involves the following main steps:

- **Configuration Phase**: The configuration can be provided using XML

configuration files, Java-based `@Configuration` classes, or through component
scanning with annotations like `@Component`, `@Service`, `@Repository`, or
`@Controller`.
- **Bean Definition**: Spring reads the configuration metadata and identifies which
classes need to be managed as beans.
- **Instantiation**: The container instantiates the bean by calling the constructor
of the class (either a default constructor or a constructor with parameters, if
specified).
- **Dependency Injection**: Spring injects the dependencies defined for the bean
(either through constructor injection, setter injection, or field injection).
- **Initialization**: If the bean implements `InitializingBean` or has an `init-
method` specified, the `afterPropertiesSet()` method or `init-method` is called to
perform any custom initialization logic.
- **Ready for Use**: The bean is ready to be used by the application.
- **Post-Initialization**: Beans can also go through `BeanPostProcessor` callbacks
to allow for additional processing before the bean is fully available.

### 2. **When Are Beans Created?**

The timing of bean creation depends on the bean's lifecycle configuration:

- **Eager Initialization (Default)**: By default, Spring creates and initializes

beans at the time of application context startup. These are called **singleton
beans**. This means that all singleton beans are instantiated when the application
context is loaded, which ensures that they are ready for use as soon as the
application is up.
- **Lazy Initialization**: You can specify that a bean should be lazily initialized
using the `@Lazy` annotation or by setting `lazy-init="true"` in the XML
configuration. This means that the bean will not be created until it is first
requested by the application.
```java
@Lazy
@Component
public class LazyBean {
public LazyBean() {
System.out.println("LazyBean created");
}
}
```

- **Prototype Beans**: Beans defined with the `@Scope("prototype")` or

`scope="prototype"` are created each time they are requested from the container,
meaning they are not initialized at startup but only when needed.

### 3. **Bean Scopes and Their Impact on Creation**

The timing of bean creation can vary based on the scope of the bean:
- **Singleton**: Only one instance of the bean is created and maintained by the
container. It is created when the application context is initialized (eager by
default).
- **Prototype**: A new instance is created every time the bean is requested.
Creation happens at the time of request, not at the application context startup.
- **Request**: In a web application, a new bean instance is created for each HTTP
request.
- **Session**: A bean is created once per HTTP session.
- **Application**: A bean is scoped to the lifecycle of a ServletContext.
- **WebSocket**: A bean is scoped to a WebSocket session.

### 4. **How Beans Are Managed (Annotations and XML)**

- **Annotations**:
- `@Component`, `@Service`, `@Repository`, and `@Controller` are used to mark
classes for automatic detection and registration as beans in the application
context.
- `@Bean` is used in Java configuration classes (`@Configuration`) to define
beans programmatically.
```java
@Configuration
public class AppConfig {
@Bean
public MyService myService() {
return new MyService();
}
}
```

- **XML Configuration**:
Beans can also be defined using XML files with the `<bean>` tag:
```xml
<bean id="myService" class="com.example.MyService" />
```

### 5. **Bean Lifecycle Callbacks**

- **`@PostConstruct` and `@PreDestroy`**: These annotations are used to define
methods that should run after the bean's properties are set (initialization) and
before the bean is destroyed (cleanup), respectively.
- **`InitializingBean` and `DisposableBean`** interfaces: Implement these
interfaces to define `afterPropertiesSet()` and `destroy()` methods for
initialization and destruction logic.

### Summary
- **Beans are created by the Spring IoC container** when the application context is
initialized for singleton beans.
- **Lazy-initialized beans** are created when they are first requested.
- **Prototype-scoped beans** are created each time they are requested from the
container.
- Beans can be configured and managed using annotations (`@Component`, `@Service`,
etc.), Java configuration (`@Bean`), or XML.

Understanding how and when beans are created allows developers to optimize
performance and resource usage in a Spring application, ensuring that beans are
initialized only when needed.
=======================
Here's a simple example to demonstrate the immutability of `String` in Java:

### Explanation of String Immutability:

In Java, `String` objects are immutable, which means that once a `String` object is
created, its value cannot be changed. Any operation that seems to modify a `String`
actually creates a new `String` object rather than modifying the existing one.

### Example Code:

```java
public class StringImmutabilityExample {
public static void main(String[] args) {
String str = "Hello"; // Original string
System.out.println("Original string: " + str);

// Attempting to change the string by appending a value

String newStr = str.concat(", World!");

// Printing the results

 System.out.println("String after concatenation: " + str);
System.out.println("New string after concatenation: " + newStr);

// Comparing memory references

System.out.println("Are str and newStr the same object? " + (str ==
newStr));
}
}
```

### Explanation:
1. The `str` variable is initialized with the value `"Hello"`.
2. When `str.concat(", World!")` is called, it does **not** modify `str`. Instead,
it creates a new `String` object containing `"Hello, World!"` and returns its
reference.
3. The original `str` still points to `"Hello"`, showing that the original string
has not changed.
4. The output will confirm that `str` and `newStr` are different objects with
different content.

### Expected Output:

```
Original string: Hello
String after concatenation: Hello
New string after concatenation: Hello, World!
Are str and newStr the same object? false
```

### Key Points:

- **Immutability** ensures that `String` objects can be safely shared between
threads without synchronization.
- Any operation that modifies a `String` returns a new `String` object, leaving the
original unchanged.
======================
Yes, `HashMap` is part of the **Java Collections Framework**, but it's not part of
the **Collection** interface hierarchy. Instead, it implements the **Map**
interface.

### Explanation:
- The **Java Collections Framework** is a unified architecture for representing and
manipulating collections of objects. It includes interfaces, implementations (e.g.,
classes), and algorithms.
- The **Collection** interface is the root interface for collections like **List**,
**Set**, and **Queue**.
- **`HashMap`** implements the **`Map`** interface, which is a separate part of the
collections framework for storing key-value pairs.

### Key Points about `HashMap`:

- **`HashMap`** is used to store data in key-value pairs.
- It allows for constant-time performance for the basic operations like get and
put, assuming the hash function disperses the elements properly.
- It permits `null` values and one `null` key.
- `HashMap` is not synchronized. If you need a thread-safe map, you should use
`Collections.synchronizedMap()` or `ConcurrentHashMap`.

### Hierarchy:
- **`Map`** Interface (parent interface for key-value data structures)
- **`HashMap`** (implements `Map`)
- **`TreeMap`**, **`LinkedHashMap`**, and other classes also implement the `Map`
interface.

### Example Code:

```java
import java.util.HashMap;
import java.util.Map;

public class HashMapExample {

public static void main(String[] args) {
Map<String, Integer> map = new HashMap<>();
map.put("One", 1);
map.put("Two", 2);
map.put("Three", 3);

System.out.println("HashMap contents: " + map);

}
}
```

### Summary:
While `HashMap` is part of the Java Collections Framework, it is not part of the
`Collection` interface hierarchy. Instead, it belongs to the `Map` interface, which
is designed for key-value pairs.
=======================================
To use an `Employee` object as a key in a `HashMap`, you should ensure that the
`Employee` class correctly overrides the `hashCode()` and `equals()` methods. This
is necessary because `HashMap` relies on these methods to determine the equality of
keys and to maintain efficient access to the data.

### Steps to Make an `Employee` Object Usable as a Key:

1. **Override the `hashCode()` method**: This method generates an integer hash code
for the object, which is used by the `HashMap` to store the key in the appropriate
bucket.
2. **Override the `equals()` method**: This method checks whether two `Employee`
objects are considered equal. If two objects are considered equal by `equals()`,
they must have the same `hashCode()`.

### Example `Employee` Class:

```java
import java.util.Objects;

public class Employee {

private int id;
private String name;

// Constructor
public Employee(int id, String name) {
this.id = id;
this.name = name;
}

// Getters (optional)
public int getId() {
return id;
}

public String getName() {

return name;
}
 // Override hashCode
@Override
public int hashCode() {
return Objects.hash(id, name);
}

// Override equals
@Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj == null || getClass() != obj.getClass()) {
return false;
}
Employee employee = (Employee) obj;
return id == employee.id && Objects.equals(name, employee.name);
}

@Override
public String toString() {
return "Employee{id=" + id + ", name='" + name + "'}";
}
}
```

### Using `Employee` as a Key in a `HashMap`:

```java
import java.util.HashMap;
import java.util.Map;

public class Main {

public static void main(String[] args) {
// Create a HashMap with Employee as the key
Map<Employee, String> employeeMap = new HashMap<>();

Employee emp1 = new Employee(1, "Alice");

Employee emp2 = new Employee(2, "Bob");
Employee emp3 = new Employee(1, "Alice"); // Same data as emp1

// Put employees in the map

employeeMap.put(emp1, "HR Department");
employeeMap.put(emp2, "Finance Department");

// Check if emp3 (same as emp1) is recognized as the same key

System.out.println("emp1 equals emp3: " + emp1.equals(emp3)); // Should
print true
System.out.println("Contains emp3 as key: " +
employeeMap.containsKey(emp3)); // Should print true

// Print the map

System.out.println("Employee Map: " + employeeMap);
}
}
```

### Explanation:
- **`hashCode()`**: Generates a consistent hash code for `Employee` objects based
on their `id` and `name`.
- **`equals()`**: Compares the `id` and `name` to check if two `Employee` objects
are equal.
- If two `Employee` objects have the same `id` and `name`, they will be treated as
the same key in the `HashMap`.

### Important Points:

- It is essential that if `equals()` returns `true` for two objects, their
`hashCode()` values must be the same.
- Failure to correctly override these methods can lead to unexpected behavior, such
as duplicate entries or inability to find keys.
============================
`Hashtable` and `ConcurrentHashMap` are both classes in Java used for key-value
pair data storage, but they differ significantly in terms of performance, thread-
safety mechanisms, and modern usage. Here's a comparison:

### 1. **Thread-Safety Mechanism**:

- **`Hashtable`**:
- **Synchronized on every method**: All public methods in `Hashtable` are
synchronized, meaning only one thread can access a method at a time. This provides
thread-safety but causes a significant performance bottleneck when multiple threads
access the `Hashtable` concurrently.
- **Full lock**: The entire `Hashtable` is locked during any read/write
operation, leading to poor concurrency.

- **`ConcurrentHashMap`**:
- **Segmented locking (in Java 7)**: Initially, `ConcurrentHashMap` used a
concept called "segmenting," where the map was divided into segments, allowing
multiple threads to read and write concurrently without locking the entire
structure.
- **Fine-grained locking (in Java 8 and above)**: The segment-based structure was
removed in Java 8, replaced with finer-grained control at the bucket level. This
allows for better performance and higher concurrency since different threads can
operate on different buckets simultaneously.
- **Read operations** are often non-blocking, providing faster access.

### 2. **Performance**:
- **`Hashtable`**:
- Performance suffers significantly when there is a high level of concurrency due
to the full locking mechanism.
- Not recommended for high-concurrency applications because of its simplistic
synchronization strategy.

- **`ConcurrentHashMap`**:
- Performs much better under concurrent access because it allows multiple threads
to read and write without blocking each other, thanks to its fine-grained locking.
- Suitable for applications requiring high concurrency without a substantial
performance hit.

### 3. **Null Keys and Values**:

- **`Hashtable`**:
- Does **not** allow `null` keys or `null` values. Attempting to add `null` will
throw a `NullPointerException`.
- **`ConcurrentHashMap`**:
- Also **does not allow `null` keys or `null` values**. This is to prevent
ambiguity in concurrent programming where `null` could signify either an absence of
a value or a `null` reference itself.

### 4. **Modern Usage and Recommendations**:

- **`Hashtable`**:
- Considered a legacy class and generally not used in new applications. Its
synchronization mechanism is outdated, and better alternatives are available.
- It has been effectively replaced by `ConcurrentHashMap` for thread-safe
operations.
- **`ConcurrentHashMap`**:
- Part of the `java.util.concurrent` package, designed with concurrency in mind
and optimized for use in multi-threaded environments.
- Highly recommended for concurrent access in modern Java applications.

### 5. **Iteration**:
- **`Hashtable`**:
- Uses the fail-fast iterator. If the structure is modified after the iterator is
created (except through the iterator’s own `remove` method), it will throw a
`ConcurrentModificationException`.
- **`ConcurrentHashMap`**:
- Uses a fail-safe iterator that does **not throw
`ConcurrentModificationException`** even if the map is modified during iteration.
It reflects changes made after the iterator was created to a certain extent but
does not guarantee to show all concurrent updates.

### 6. **Example Usage**:

**`Hashtable`**:
```java
import java.util.Hashtable;

public class HashtableExample {

public static void main(String[] args) {
Hashtable<String, Integer> hashtable = new Hashtable<>();
hashtable.put("One", 1);
hashtable.put("Two", 2);

System.out.println("Hashtable: " + hashtable);

}
}
```

**`ConcurrentHashMap`**:
```java
import java.util.concurrent.ConcurrentHashMap;

public class ConcurrentHashMapExample {

public static void main(String[] args) {
ConcurrentHashMap<String, Integer> concurrentMap = new
ConcurrentHashMap<>();
concurrentMap.put("One", 1);
concurrentMap.put("Two", 2);

System.out.println("ConcurrentHashMap: " + concurrentMap);

}
}
```

### **Summary**:
- **Use `Hashtable`** only if working with legacy code that requires it.
- **Use `ConcurrentHashMap`** for any new development that requires thread-safe
operations on a `Map`. It is more efficient, modern, and designed for high
concurrency scenarios.
==========================
`Comparator` and `Comparable` are both interfaces in Java used for sorting objects.
They are part of the `java.util` package and help in defining custom sorting logic.
However, they have different purposes and usage. Here’s a detailed comparison:

### 1. **Definition**:
- **`Comparable`**:
- An interface used to define the natural ordering of objects of a class.
- The class that implements `Comparable` must override the `compareTo()` method.
- Located in the `java.lang` package.

- **`Comparator`**:
- An interface used to define a custom or external sorting logic that can be used
for classes whose natural ordering you do not want to modify or for defining
multiple sorting sequences.
- Implemented by a separate class that overrides the `compare()` method.
- Located in the `java.util` package.

### 2. **Method to Implement**:

- **`Comparable`**:
- Method to override: `int compareTo(T o)`
- Syntax:
```java
@Override
public int compareTo(T o) {
// Return a negative integer, zero, or a positive integer
// as this object is less than, equal to, or greater than the specified
object.
}
```

- **`Comparator`**:
- Method to override: `int compare(T o1, T o2)`
- Syntax:
```java
@Override
public int compare(T o1, T o2) {
// Return a negative integer, zero, or a positive integer
// as the first argument is less than, equal to, or greater than the
second.
}
```

### 3. **Usage**:
- **`Comparable`**:
- Used when there is a **natural ordering** of objects. For example, sorting
`String`, `Integer`, or custom classes like `Student` by `id` or `name` in a
predefined way.
- Example of implementing `Comparable`:
```java
public class Student implements Comparable<Student> {
private int id;
private String name;

public Student(int id, String name) {

this.id = id;
this.name = name;
}

@Override
 public int compareTo(Student other) {
return this.id - other.id; // Sorts by id in ascending order
}
}
```

- **`Comparator`**:
- Used when you want to define **custom sorting logic** or **multiple sorting
strategies**. For example, sorting a `Student` class by `name`, `age`, etc.
- Example of using `Comparator`:
```java
import java.util.Comparator;

public class StudentNameComparator implements Comparator<Student> {

@Override
public int compare(Student s1, Student s2) {
return s1.getName().compareTo(s2.getName()); // Sorts by name in
ascending order
}
}
```

### 4. **Flexibility**:
- **`Comparable`**:
- Allows sorting based on **one attribute** or a single natural order only. It
requires modification of the class itself to change the comparison logic.
- **`Comparator`**:
- Offers greater flexibility as you can create multiple `Comparator`
implementations to sort objects based on different attributes without modifying the
class itself.

### 5. **Multiple Sorting**:

- **`Comparable`**:
- Not suitable for scenarios where multiple sorting orders are needed.
- **`Comparator`**:
- Can be used to define multiple sorting orders. For example:
```java
Comparator<Student> byId = (s1, s2) -> s1.getId() - s2.getId();
Comparator<Student> byName = (s1, s2) -> s1.getName().compareTo(s2.getName());
```

### 6. **Example Usage in Sorting**:

- **Using `Comparable`**:
```java
List<Student> students = new ArrayList<>();
students.add(new Student(2, "John"));
students.add(new Student(1, "Alice"));

Collections.sort(students); // Uses compareTo() defined in Student class

```

- **Using `Comparator`**:
```java
List<Student> students = new ArrayList<>();
students.add(new Student(2, "John"));
students.add(new Student(1, "Alice"));

// Sort by name using a comparator

students.sort(new StudentNameComparator());
 // Alternatively, using lambda expression
students.sort((s1, s2) -> s1.getId() - s2.getId());
```

### **Summary**:
- **`Comparable`** is best suited for defining the natural order of objects
directly in the class itself.
- **`Comparator`** is more flexible, allowing you to define multiple ways of
comparing objects without altering the class code.
- Choose `Comparable` for single natural ordering and `Comparator` for more complex
or multiple sorting requirements.
=========================
A Singleton class in Java is a design pattern that ensures that only **one
instance** of the class is created throughout the lifetime of an application. This
pattern is widely used to control access to shared resources, provide coordinated
access, and optimize memory usage. Here are some common scenarios and use cases
where a Singleton class is beneficial:

### 1. **Configuration or Settings Class**:

- A Singleton can be used to manage the global configuration or settings of an
application. For instance, reading configuration properties from a file or storing
global application settings that need to be accessed in a consistent manner.
- Example: `ConfigurationManager` class that reads and caches properties from a
config file.

### 2. **Logging**:
- A logging class is a classic example of using a Singleton pattern. Creating
multiple instances of a logger could lead to performance issues and inconsistent
log outputs.
- Example: A `Logger` class that ensures all parts of an application write logs
using a single shared instance.

### 3. **Database Connection Pool**:

- A Singleton is used to manage a pool of database connections. Having a
centralized object that handles database connections improves resource management
and prevents multiple connections from being created unnecessarily.
- Example: `DatabaseConnectionManager` that provides synchronized access to
database resources.

### 4. **Thread Pool Management**:

- Singleton is used to control and coordinate access to a thread pool. This
ensures that thread management is centralized and shared across the application.
- Example: `ThreadPoolExecutor` instance management in multi-threaded
applications.

### 5. **Caching**:
- A Singleton class can be used for caching data that needs to be shared across
multiple parts of the application. This helps in reducing the need for redundant
data fetching or computation.
- Example: `CacheManager` that stores frequently accessed data and ensures
consistent data availability.

### 6. **Resource Management**:

- Singleton classes can be used to manage resources such as file handlers,
memory management, or network connections. This ensures that these expensive
resources are used efficiently.
- Example: `FileHandler` or `NetworkConnectionManager` that centralizes access
to files or network resources.
### 7. **Controller Objects in MVC Pattern**:
- In the Model-View-Controller (MVC) architecture, a controller may be
implemented as a Singleton to ensure that all requests go through a single access
point.
- Example: `FrontController` or `RequestHandler`.

### 8. **Service Locator**:

- A Singleton can be used as a service locator that holds references to service
objects. It acts as a registry for services that different parts of an application
may need to use.
- Example: `ServiceLocator` that provides instances of various service classes.

### 9. **Factories and Managers**:

- Factories or manager classes that create or manage objects are often
implemented as Singletons. This ensures consistent and controlled object creation.
- Example: `ConnectionFactory` or `SessionManager`.

### **Advantages of Singleton Pattern**:

- **Controlled access to a single instance**: Ensures that there is controlled
access to a single, consistent instance.
- **Reduced memory usage**: Helps in saving memory by avoiding the creation of
multiple instances.
- **Consistent state**: Helps in maintaining a consistent state across the
application.
- **Easy to coordinate**: Simplifies coordinating actions that require shared
access.

### **How to Implement a Basic Singleton Class**:

```java
public class SingletonExample {
// Private static variable to hold the single instance
private static SingletonExample instance;

// Private constructor to prevent instantiation from other classes

private SingletonExample() {
}

// Public method to provide access to the instance

public static SingletonExample getInstance() {
if (instance == null) {
instance = new SingletonExample();
}
return instance;
}
}
```

### **Thread-Safe Singleton Implementation**:

For multi-threaded environments, it’s important to make the Singleton
implementation thread-safe.

```java
public class ThreadSafeSingleton {
private static ThreadSafeSingleton instance;

private ThreadSafeSingleton() {
}
 public static synchronized ThreadSafeSingleton getInstance() {
if (instance == null) {
instance = new ThreadSafeSingleton();
}
return instance;
}
}
```

### **Usage**:
To use a Singleton, you simply call the `getInstance()` method:
```java
SingletonExample singleton = SingletonExample.getInstance();
```

### **Conclusion**:
Singleton classes are highly useful for cases where only one instance of a class
should exist to coordinate actions or share resources. However, be cautious with
their use to avoid issues such as tightly coupled code and difficulties in testing.
=================================
While singleton classes are designed to prevent the creation of multiple instances,
there are some ways to break the singleton pattern. Here are the most common
techniques that can compromise a singleton:

### 1. **Reflection**
Using Java Reflection, you can bypass the private constructor and create a new
instance of the singleton class.

**Example:**
```java
import java.lang.reflect.Constructor;

public class SingletonBreaker {

public static void main(String[] args) {
SingletonClass instance1 = SingletonClass.getInstance();

SingletonClass instance2 = null;

try {
Constructor<SingletonClass> constructor =
SingletonClass.class.getDeclaredConstructor();
constructor.setAccessible(true); // Bypass private constructor
instance2 = constructor.newInstance();
} catch (Exception e) {
e.printStackTrace();
}

System.out.println("Instance 1 hash: " + instance1.hashCode());

System.out.println("Instance 2 hash: " + instance2.hashCode());
}
}

// Singleton class
class SingletonClass {
private static SingletonClass instance;

private SingletonClass() {
// Prevent reflection attack
if (instance != null) {
throw new RuntimeException("Use getInstance() method to create");
 }
}

public static SingletonClass getInstance() {

if (instance == null) {
instance = new SingletonClass();
}
return instance;
}
}
```

### 2. **Serialization and Deserialization**

When a singleton class implements `Serializable`, deserialization can create a new
instance of the class, thus breaking the singleton pattern.

**Example:**
```java
import java.io.*;

public class SingletonSerializationBreaker {

public static void main(String[] args) {
SingletonClass instance1 = SingletonClass.getInstance();

try (ObjectOutputStream out = new ObjectOutputStream(new

FileOutputStream("singleton.ser"))) {
out.writeObject(instance1);
} catch (IOException e) {
e.printStackTrace();
}

SingletonClass instance2 = null;

try (ObjectInputStream in = new ObjectInputStream(new
FileInputStream("singleton.ser"))) {
instance2 = (SingletonClass) in.readObject();
} catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}

System.out.println("Instance 1 hash: " + instance1.hashCode());

System.out.println("Instance 2 hash: " + instance2.hashCode());
}
}

// Singleton class with Serializable

class SingletonClass implements Serializable {
private static final long serialVersionUID = 1L;
private static SingletonClass instance;

private SingletonClass() {
// Prevent instantiation via reflection
if (instance != null) {
throw new RuntimeException("Use getInstance() method to create");
}
}

public static SingletonClass getInstance() {

if (instance == null) {
instance = new SingletonClass();
 }
return instance;
}

// Resolve deserialization issue by using readResolve

protected Object readResolve() {
return instance;
}
}
```

### 3. **Cloning**
Implementing the `Cloneable` interface allows object cloning, which can break the
singleton pattern.

**Example:**
```java
public class SingletonCloneBreaker {
public static void main(String[] args) throws CloneNotSupportedException {
SingletonClass instance1 = SingletonClass.getInstance();
SingletonClass instance2 = (SingletonClass) instance1.clone();

System.out.println("Instance 1 hash: " + instance1.hashCode());

System.out.println("Instance 2 hash: " + instance2.hashCode());
}
}

// Singleton class with Cloneable

class SingletonClass implements Cloneable {
private static SingletonClass instance;

private SingletonClass() {
if (instance != null) {
throw new RuntimeException("Use getInstance() method to create");
}
}

public static SingletonClass getInstance() {

if (instance == null) {
instance = new SingletonClass();
}
return instance;
}

@Override
protected Object clone() throws CloneNotSupportedException {
return instance; // Prevent cloning
}
}
```

### 4. **Multithreading Issues**

If the singleton class is not properly synchronized, multiple threads can create
multiple instances.

**Example Solution:**
Use the `synchronized` keyword or implement the **Double-Checked Locking** pattern
to prevent multithreading issues:
```java
public class ThreadSafeSingleton {
private static volatile ThreadSafeSingleton instance;

private ThreadSafeSingleton() {
if (instance != null) {
throw new RuntimeException("Use getInstance() method to create");
}
}

public static ThreadSafeSingleton getInstance() {

if (instance == null) {
synchronized (ThreadSafeSingleton.class) {
if (instance == null) {
instance = new ThreadSafeSingleton();
}
}
}
return instance;
}
}
```

### **Conclusion**
To protect a singleton from being broken:
- **Prevent reflection** by adding a check in the constructor.
- **Override `readResolve()`** to prevent deserialization issues.
- **Override `clone()`** or throw an exception to prevent cloning.
- **Ensure thread-safety** with proper synchronization techniques.

Understanding and securing these vulnerabilities will help maintain the integrity
of a singleton class.
==================================
When a class implements the `Serializable` interface, it means that its objects can
be converted into a byte stream and subsequently reconstructed from that stream.
However, if a `Serializable` class contains non-serializable instance variables,
the following outcomes are possible:

### 1. **`NotSerializableException`**
If the non-serializable field is an instance of a class that does **not** implement
`Serializable`, and no special handling is provided, a
`java.io.NotSerializableException` will be thrown when trying to serialize the
object.

**Example:**
```java
import java.io.*;

class NonSerializableClass {
int value = 100;
}

class SerializableClass implements Serializable {

private static final long serialVersionUID = 1L;
int id;
transient NonSerializableClass nonSerializableField; // Non-serializable

public SerializableClass(int id) {

this.id = id;
this.nonSerializableField = new NonSerializableClass();
 }
}

public class Main {

public static void main(String[] args) {
SerializableClass obj = new SerializableClass(42);

try (ObjectOutputStream out = new ObjectOutputStream(new

FileOutputStream("object.ser"))) {
out.writeObject(obj); // This will throw NotSerializableException
} catch (IOException e) {
e.printStackTrace();
}
}
}
```

### 2. **Using `transient` Keyword**

If you declare a non-serializable field as `transient`, it will be skipped during
the serialization process. When the object is deserialized, this field will be set
to its default value (e.g., `null` for object references, `0` for integers).

**Example with `transient`:**

```java
import java.io.*;

class NonSerializableClass {
int value = 100;
}

class SerializableClass implements Serializable {

private static final long serialVersionUID = 1L;
int id;
transient NonSerializableClass nonSerializableField; // Skipped during
serialization

public SerializableClass(int id) {

this.id = id;
this.nonSerializableField = new NonSerializableClass();
}
}

public class Main {

public static void main(String[] args) {
SerializableClass obj = new SerializableClass(42);

// Serialize the object

try (ObjectOutputStream out = new ObjectOutputStream(new
FileOutputStream("object.ser"))) {
out.writeObject(obj);
} catch (IOException e) {
e.printStackTrace();
}

// Deserialize the object

try (ObjectInputStream in = new ObjectInputStream(new
FileInputStream("object.ser"))) {
SerializableClass deserializedObj = (SerializableClass)
in.readObject();
 System.out.println("ID: " + deserializedObj.id);
System.out.println("Non-serializable field: " +
deserializedObj.nonSerializableField); // Will print null
} catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
}
}
```

### 3. **Custom Serialization with `writeObject()` and `readObject()`**

If you need to handle non-serializable fields during serialization, you can
implement custom `writeObject()` and `readObject()` methods in your class. This
allows you to define how the non-serializable field should be serialized (e.g., by
saving only some of its state).

**Example of custom handling:**

```java
import java.io.*;

class NonSerializableClass {
int value = 100;
}

class SerializableClass implements Serializable {

private static final long serialVersionUID = 1L;
int id;
transient NonSerializableClass nonSerializableField; // Custom handling
required

public SerializableClass(int id) {

this.id = id;
this.nonSerializableField = new NonSerializableClass();
}

private void writeObject(ObjectOutputStream out) throws IOException {

out.defaultWriteObject(); // Serialize default fields
// Custom serialization for non-serializable field
out.writeInt(nonSerializableField != null ? nonSerializableField.value : -
1);
}

private void readObject(ObjectInputStream in) throws IOException,

ClassNotFoundException {
in.defaultReadObject(); // Deserialize default fields
// Custom deserialization for non-serializable field
int value = in.readInt();
if (value != -1) {
nonSerializableField = new NonSerializableClass();
nonSerializableField.value = value;
}
}
}

public class Main {

public static void main(String[] args) {
SerializableClass obj = new SerializableClass(42);

// Serialize the object

 try (ObjectOutputStream out = new ObjectOutputStream(new
FileOutputStream("object.ser"))) {
out.writeObject(obj);
} catch (IOException e) {
e.printStackTrace();
}

// Deserialize the object

try (ObjectInputStream in = new ObjectInputStream(new
FileInputStream("object.ser"))) {
SerializableClass deserializedObj = (SerializableClass)
in.readObject();
System.out.println("ID: " + deserializedObj.id);
System.out.println("Non-serializable field value: " +
(deserializedObj.nonSerializableField != null ?
deserializedObj.nonSerializableField.value : "null"));
} catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
}
}
```

### **Summary**
- **Non-serializable fields** cause `NotSerializableException` unless marked
`transient` or handled via custom methods.
- **`transient` fields** are ignored during serialization and deserialization.
- Custom serialization using `writeObject()` and `readObject()` methods can handle
non-serializable fields safely.
===========================
In Spring, `Singleton` and `Prototype` are two common **scopes** that determine how
bean instances are managed in the container. Understanding these scopes is
essential for controlling the lifecycle of beans in a Spring application.

### 1. **Singleton Scope**

- **Definition**: The `singleton` scope ensures that a single instance of a bean is
created and shared throughout the Spring container. This is the **default** scope
in Spring.
- **Characteristics**:
- Only one instance of the bean exists per Spring IoC container.
- Each time the bean is requested, the same instance is returned.
- This scope is suitable for stateless beans or beans that are shared across
multiple parts of the application.
- **Use Case**: Use `singleton` scope for beans that do not maintain any state or
have a shared, immutable state, such as configuration or utility classes.

**Example**:
```java
@Component
public class SingletonBean {
public SingletonBean() {
System.out.println("SingletonBean instance created");
}
}

// Each request for `SingletonBean` will return the same instance.

```

### 2. **Prototype Scope**

- **Definition**: The `prototype` scope creates a new instance of the bean every
time it is requested.
- **Characteristics**:
- A new instance is returned for each request.
- The Spring container does not manage the complete lifecycle of a `prototype`
bean. It creates, initializes, and hands off the instance, but it does not track or
destroy it.
- This scope is useful for stateful beans or beans that need to be unique for
each use.
- **Use Case**: Use `prototype` scope when you need a new instance for each request
or operation, such as beans that represent a user session, temporary data, or
specific task-related objects.

**Example**:
```java
@Component
@Scope("prototype")
public class PrototypeBean {
public PrototypeBean() {
System.out.println("PrototypeBean instance created");
}
}

// Each request for `PrototypeBean` will create a new instance.

```

### **Key Differences Between Singleton and Prototype**:

| Aspect | Singleton | Prototype
|
|-------------------|---------------------------------|----------------------------
-----|
| **Instance Count**| Single instance per Spring container | New instance for each
request |
| **Lifecycle** | Managed by Spring (creation and destruction) | Managed only
during creation |
| **Use Cases** | Stateless/shared beans | Stateful/unique instances
|
| **Performance** | Efficient, as only one instance is reused | Less efficient,
new instance per use |

### **How to Configure These Scopes**:

1. **Annotation-Based Configuration**:
- Use `@Scope("singleton")` (optional as it's the default) or
`@Scope("prototype")` on a class annotated with `@Component`, `@Service`,
`@Repository`, or `@Controller`.

**Example**:
```java
@Component
@Scope("prototype")
public class ExampleBean {
// Bean logic here
}
```

2. **XML-Based Configuration**:
- In `beans.xml`, use the `scope` attribute:
```xml
<bean id="exampleBean" class="com.example.ExampleBean" scope="prototype" />
 ```

### **Summary**:
- **Singleton** is used for beans where one shared instance is sufficient.
- **Prototype** is used for beans where a new, unique instance is needed for each
use.

Choosing between these scopes depends on your application's requirements and

whether the bean needs to be stateless or stateful.
==========================