Amol Pawar

Java’s threading model can trip up even experienced developers. One of the most common sources of confusion? The difference between t.start() and t.run().

If you’ve ever written a multithreaded program in Java, you’ve likely encountered both. But what actually happens when you call t.start() instead of t.run() — and why does it matter?

Quick Answer: t.start() vs t.run()

• t.start(): Starts a new thread and executes the run() method in that new thread.
• t.run(): Calls the run() method in the current thread, just like a normal method.

Sounds simple, right? But the consequences are huge.

Let’s break it down with code examples and real-world implications.

A Little Threading Background

Java supports multithreading — the ability to run multiple threads (independent units of work) simultaneously. You can create threads by:

1. Extending the Thread class.
2. Implementing the Runnable interface.

In both cases, you override the run() method, which holds the code you want the thread to execute.

But here’s the twist: overriding run() doesn’t actually start the thread. That’s what start() is for.

t.start() vs t.run() in Action

public class Demo extends Thread {
    public void run() {
        System.out.println("Running in: " + Thread.currentThread().getName());
    }

public static void main(String[] args) {
        Demo t1 = new Demo();
        System.out.println("Calling t1.run()");
        t1.run();  // Executes in main thread
        System.out.println("Calling t1.start()");
        t1.start();  // Executes in new thread
    }
}

Output:

Calling t1.run()
Running in: main
Calling t1.start()
Running in: Thread-0

What’s Happening Here?

• t1.run() runs just like any regular method — in the main thread.
• t1.start() creates a new thread and calls run() in that thread.

That’s the real difference between t.start() vs t.run().

Why It Matters: Real-World Implications

1. Concurrency

Using t.start() enables true parallel execution. Your app can do multiple things at once.

Using t.run()? Everything runs sequentially in the same thread. No concurrency. Just like calling any other method.

2. Performance

On multi-core processors, t.start() lets Java take full advantage of your CPU. Each thread can run independently.

t.run()? No benefit — it runs synchronously, blocking other operations.

3. Thread Behavior

start() sets up everything: thread stack, scheduling, life cycle management.

run() bypasses that. You’re not creating a new thread; you’re just executing some code.

Common Mistakes to Avoid

Mistake 1: Using t.run() and expecting multithreading

Thread t = new Thread(() -> {
    System.out.println("Running in: " + Thread.currentThread().getName());
});

t.run(); // Looks like threading, but isn't!

You just called a method. No new thread is created. Use t.start() instead.

Mistake 2: Calling start() twice

Thread t = new Thread(() -> {
    System.out.println("Hello!");
});

t.start();  // OK
t.start();  // IllegalThreadStateException

Once a thread has been started, it can’t be restarted. You’ll get a runtime exception if you try.

Practical Tip: Always Use start() for Threads

If your goal is concurrency, always use start(). The only time you’d use run() directly is for testing or if you’re intentionally avoiding multithreading (rare).

Loop with Threads

for (int i = 0; i < 3; i++) {
    Thread t = new Thread(() -> {
        System.out.println("Running in: " + Thread.currentThread().getName());
    });
    t.start();  // Right choice
}

Want concurrency? Use start() — always.

t.start() vs t.run() in Java

When comparing t.start() vs t.run(), the key takeaway is this:

• start() kicks off a new thread.
• run() just runs the code in the current thread.

If you want real multithreading, go with t.start(). If you call t.run(), you’re just calling a method — no thread magic involved.

This difference is critical when building responsive, scalable Java applications — whether it’s for a web server, a game engine, or a background worker.

Key Takeaways

• t.start() creates a new thread and calls run() in it.
• t.run() runs like a normal method — no new thread.
• Always use start() to actually start threading.
• Don’t call start() more than once on the same thread.
• If it runs in the main thread, it’s not really multithreaded.

Conclusion

Understanding t.start() vs t.run() is foundational for writing efficient, concurrent Java programs. It’s not just about syntax — it’s about how your code executes in real time.

So next time you see run(), stop and ask: Am I actually starting a thread, or just calling a method?

If you want true multithreading, start() is your ticket.

Java is a strongly typed language, meaning it requires explicit type definitions to ensure reliability and stability in applications. One of the most powerful features Java provides to enforce type safety in Java is Generics. This guide will help you understand generics, how they enhance type safety, and how to use them effectively.

What Are Generics in Java?

Generics allow developers to create classes, interfaces, and methods that operate on different types while maintaining type safety in Java. With generics, you can write flexible and reusable code without compromising the reliability of type enforcement.

For example, before generics were introduced, Java collections stored objects as raw types, requiring explicit casting, which was both error-prone and unsafe.

Without Generics (Before Java 5)

import java.util.ArrayList;

public class WithoutGenerics {
    public static void main(String[] args) {
        ArrayList list = new ArrayList(); // Raw type list
        list.add("Hello");
        list.add(100); // No type safety
        String text = (String) list.get(0); // Safe
        String number = (String) list.get(1); // Runtime error: ClassCastException
    }
}

Have you noticed Problem Here:

• The ArrayList stores any object type (String, Integer, etc.), leading to runtime errors.
• Type casting is required when retrieving elements, otherwise, which increases the chance of ClassCastException.

How Generics Improve Type Safety in Java

With generics, you specify the type when defining a collection, ensuring only valid data types are added.

With Generics (Java 5 and Later)

import java.util.ArrayList;

public class WithGenerics {
    public static void main(String[] args) {
        ArrayList<String> list = new ArrayList<>(); // Type-safe list
        list.add("Hello");
        // list.add(100); // Compile-time error, preventing mistakes
        String text = list.get(0); // No explicit casting required
        System.out.println(text);
    }
}

Benefits of Generics:

1. Compile-time Type Checking: Prevents type-related errors at compile time instead of runtime.
2. No Need for Type Casting: Eliminates unnecessary type conversion, reducing code complexity.
3. Code Reusability: Generic methods and classes can work with multiple types without duplication.

Using Generics in Classes

You can define generic classes to work with different data types.

Creating a Generic Class

A generic class is a class that can work with any data type. You define it using type parameters inside angle brackets (<>).

class Box<T> { // T is a placeholder for a type
    private T value;
    
    public void setValue(T value) {
        this.value = value;
    }
    
    public T getValue() {
        return value;
    }
}

public class GenericClassExample {
    public static void main(String[] args) {
        Box<String> stringBox = new Box<>();
        stringBox.setValue("Java Generics");
        System.out.println(stringBox.getValue());
        Box<Integer> intBox = new Box<>();
        intBox.setValue(100);
        System.out.println(intBox.getValue());
    }
}

Here,

• T represents a generic type that is replaced with a real type (e.g., String or Integer) when used.
• The class works for any data type while ensuring type safety in Java.

Generic Methods

Generic methods allow flexibility by defining methods that work with various types.

Creating a Generic Method

You can define methods that use generics, making them more reusable.

class GenericMethodExample {
    public static <T> void printArray(T[] elements) {
        for (T element : elements) {
            System.out.print(element + " ");
        }
        System.out.println();
    }
    
    public static void main(String[] args) {
        Integer[] intArray = {1, 2, 3, 4, 5};
        String[] strArray = {"A", "B", "C"};
        
        printArray(intArray); // Works with Integer array
        printArray(strArray); // Works with String array
    }
}

Here,

• <T> before the method name defines a generic type.
• The method works with any array type (Integer, String, etc.), enhancing type safety in Java.

Bounded Type Parameters

Sometimes, you may want to restrict the generic type to a specific category, such as only numbers. This is done using bounded type parameters.

Restricting to Number Types

class Calculator<T extends Number> { // T must be a subclass of Number
    private T num;
    
    public Calculator(T num) {
        this.num = num;
    }
    
    public double square() {
        return num.doubleValue() * num.doubleValue();
    }
}

public class BoundedGenericsExample {
    public static void main(String[] args) {
        Calculator<Integer> intCalc = new Calculator<>(5);
        System.out.println("Square: " + intCalc.square());
        Calculator<Double> doubleCalc = new Calculator<>(3.5);
        System.out.println("Square: " + doubleCalc.square());
    }
}

• T extends Number ensures that T can only be a subclass of Number (e.g., Integer, Double).
• This ensures type safety in Java, preventing incompatible types like String from being used.

Wildcards in Generics

Wildcards (?) provide flexibility when working with generics. They allow methods to accept unknown generic types.

import java.util.*;

class WildcardExample {
    public static void printList(List<?> list) {
        for (Object obj : list) {
            System.out.println(obj);
        }
    }
    public static void main(String[] args) {
        List<Integer> intList = Arrays.asList(1, 2, 3);
        List<String> strList = Arrays.asList("A", "B", "C");
        
        printList(intList);
        printList(strList);
    }
}

Why Use Wildcards?

• ? allows passing any generic type.
• Helps achieve type safety in Java while maintaining flexibility.

Conclusion

Generics are a crucial feature in Java, enhancing type safety in Java by detecting errors at compile-time and reducing runtime exceptions. By using generics, developers can create reusable, maintainable, and efficient code. Whether you use generic classes, methods, bounded types, or wildcards, generics make Java programming safer and more powerful.

Memory management is a crucial aspect of Java programming, ensuring that unused objects are efficiently cleared to free up resources. While Java’s built-in garbage collector (GC) handles most of this automatically, advanced scenarios require finer control. This is where PhantomReference in Java comes into play.

In this blog post, we will explore PhantomReference in Java, how it differs from other reference types, and how it can be used to enhance memory management. Let’s dive in!

What is PhantomReference in Java?

A PhantomReference is a type of reference in Java that allows you to determine precisely when an object is ready for finalization. Unlike SoftReference and WeakReference, a PhantomReference does not prevent an object from being collected. Instead, it serves as a mechanism to perform post-mortem cleanup operations after the object has been finalized.

Key Characteristics:

• No Direct Access: You cannot retrieve the referenced object via get(). It always returns null.
• Used for Cleanup: It is typically used for resource management, such as closing files or releasing memory in native code.
• Works with ReferenceQueue: The object is enqueued in a ReferenceQueue when the JVM determines it is ready for GC.

How PhantomReference Differs from Other References

Java provides four types of references:

• Strong Reference: The default type; prevents garbage collection.
• Weak Reference: Allows an object to be garbage collected if no strong references exist.
• Soft Reference: Used for memory-sensitive caches; objects are collected only when memory is low.
• Phantom Reference: Unlike other references, it does not prevent garbage collection at all. Instead, it is used to run cleanup actions after an object has been collected, often in conjunction with a ReferenceQueue.

Implementing PhantomReference in Java

To use PhantomReference in Java, we must associate it with a ReferenceQueue, which holds references to objects that have been marked for garbage collection.

import java.lang.ref.PhantomReference;
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;

public class PhantomReferenceExample {
    public static void main(String[] args) throws InterruptedException {
        ReferenceQueue<Resource> queue = new ReferenceQueue<>();
        Resource resource = new Resource();
        PhantomReference<Resource> phantomRef = new PhantomReference<>(resource, queue);

        // Remove strong reference
        resource = null;
        System.gc(); // Suggest GC
       
        // Wait for the reference to be enqueued
        while (queue.poll() == null) {
            System.gc();
            Thread.sleep(100);
        }
        
        System.out.println("PhantomReference enqueued, performing cleanup...");
    }
}

class Resource {
    void cleanup() {
        System.out.println("Cleaning up resources...");
    }
}

Here,

1. We create a ReferenceQueue to hold PhantomReference objects after GC determines they are unreachable.
2. A PhantomReference to a Resource object is created and linked to the queue.
3. The strong reference to the Resource object is removed (resource = null), allowing it to be garbage collected.
4. The garbage collector runs (System.gc()), and after a delay (Thread.sleep(1000)), we check the ReferenceQueue.
5. If the PhantomReference is enqueued, we perform cleanup operations before removing the reference completely.

Why Use PhantomReference?

The main reason for using PhantomReference in Java is to gain better control over memory cleanup beyond what the garbage collector offers. Some use cases include:

1. Monitoring Garbage Collection: Detect when an object is about to be collected.
2. Resource Cleanup: Free up native resources after Java objects are finalized.
3. Avoiding finalize() Method: finalize() is discouraged due to its unpredictable execution; PhantomReference provides a better alternative.

Conclusion

PhantomReference in Java is a powerful tool for managing memory efficiently. While it may not be needed in everyday development, understanding how it works helps in writing better memory-aware applications. By combining PhantomReference with a ReferenceQueue, you can ensure timely resource cleanup and improve your application’s performance.

If you’re working with large objects, native resources, or need to track garbage collection behavior, PhantomReference in Java provides a robust and flexible solution.

Java developers often get confused between final, finally, and finalize. These three terms might sound similar, but they serve completely different purposes. If you’ve ever struggled to understand their differences, this guide is for you!

By the end of this post, you’ll have a clear understanding of final vs finally vs finalize in Java and how to use each one correctly. Let’s dive in!

1. What is final in Java?

The final keyword in Java is used for constants, method restrictions, and inheritance control. It can be applied to variables, methods, and classes.

a) final with Variables (Constant Values)

When a variable is declared final, its value cannot be changed once assigned.

public class FinalVariableExample {
    final int MAX_VALUE = 100; // Constant value
    
    void display() {
        // MAX_VALUE = 200; // This will cause a compilation error
        System.out.println("Max Value: " + MAX_VALUE);
    }
}

The MAX_VALUE variable is declared as final, so its value cannot be modified.

b) final with Methods (Prevent Overriding)

A final method cannot be overridden by subclasses.

class Parent {
    final void show() {
        System.out.println("This is a final method.");
    }
}

class Child extends Parent {
    // void show() { // This will cause a compilation error
    //     System.out.println("Cannot override a final method");
    // }
}

The show() method in the Parent class is marked final, preventing the Child class from overriding it.

c) final with Classes (Prevent Inheritance)

A class declared as final cannot be extended.

final class FinalClass {
    void display() {
        System.out.println("This is a final class.");
    }
}

// class SubClass extends FinalClass { // This will cause a compilation error
// }

The FinalClass cannot be extended by any subclass.

2. What is finally in Java?

The finally block in Java is used to ensure that important code executes, regardless of exceptions. It is primarily used with try-catch blocks to handle exceptions.

public class FinallyExample {
    public static void main(String[] args) {
        try {
            int result = 10 / 0; // This will cause an exception
        } catch (ArithmeticException e) {
            System.out.println("Exception caught: " + e.getMessage());
        } finally {
            System.out.println("Finally block executed!");
        }
    }
}

Output:

Exception caught: / by zero
Finally block executed!

The finally block runs no matter what happens in the try-catch block. This is useful for closing resources like database connections or file streams.

3. What is finalize() in Java?

The finalize() method is used for garbage collection. It is called by the Garbage Collector before an object is destroyed to perform cleanup operations.

class FinalizeExample {
    protected void finalize() {
        System.out.println("Finalize method called before garbage collection.");
    }

    public static void main(String[] args) {
        FinalizeExample obj = new FinalizeExample();
        obj = null; // Making object eligible for garbage collection
        System.gc(); // Requesting garbage collection
        System.out.println("End of main method.");
    }
}

Output (may vary depending on JVM execution):

End of main method.
Finalize method called before garbage collection.

• The finalize() method is called before an object is garbage collected but not guaranteed to execute immediately or at all.
• Calling System.gc() only suggests garbage collection to the JVM, but it does not force it.
• Due to unpredictability and performance issues, finalize() has been deprecated in Java 9 and removed (marked as remove) in Java 18.

Alternatives to finalize():

• Try-with-resources (AutoCloseable) – For handling resources like files, sockets, and streams.
• java.lang.ref.Cleaner (Java 9+) – A more reliable way to register cleanup actions when objects become unreachable.

Important Note:

The use of finalize() is strongly discouraged in modern Java programming. Developers should use explicit resource management instead of relying on garbage collection for cleanup.

Final vs Finally vs Finalize in Java: Key Differences

When to Use Final, Finally, and Finalize?

• Use final when you want to create constants, prevent method overriding, or restrict class inheritance.
• Use finally when you need to execute important code regardless of exceptions, like closing resources.
• Use finalize() only if you need to clean up resources before garbage collection, though it is now discouraged.

Conclusion

Understanding final vs finally vs finalize in Java is crucial for writing efficient and error-free Java programs. While final is used for constants, method restrictions, and inheritance prevention, finally ensures essential code execution, and finalize() helps with garbage collection (though deprecated in Java 9+).

Java provides a robust exception handling mechanism that helps developers write reliable and maintainable code. While Java’s standard exceptions cover many common error scenarios, sometimes you need something more specific to your application’s needs. This is where custom exceptions in Java come into play. But when should you create a custom exception, and when is it unnecessary? Let’s explore this in depth.

What Are Standard Exceptions in Java?

Java has a rich hierarchy of built-in exceptions that developers can use to handle different errors. These standard exceptions fall into two main categories:

1. Checked Exceptions — Must be handled using try-catch or declared using throws.

• Example: IOException, SQLException

2. Unchecked Exceptions (Runtime Exceptions) — Do not require explicit handling.

• Example: NullPointerException, IndexOutOfBoundsException

Using standard exceptions is often the best choice because they are well-documented and understood by developers. However, they might not always convey specific application-related issues effectively.

When to Use Custom Exceptions in Java

Custom exceptions are useful when you need to represent domain-specific errors that are not covered by standard exceptions. Here are some scenarios where custom exceptions make sense:

1. When Standard Exceptions Are Too Generic

Standard exceptions may not always provide enough clarity. For instance, if your application processes payments, throwing a generic Exception or IllegalArgumentException isn’t informative. A PaymentProcessingException makes the error clearer.

2. When You Need to Add Extra Information

A custom exception allows you to include additional details about an error, such as error codes, messages, or even metadata.

3. When You Want to Enforce Business Rules

Custom exceptions help enforce specific business logic. For example, if a user tries to withdraw more money than available, you might throw an InsufficientFundsException instead of a generic RuntimeException.

4. When You Need to Handle Exceptions Differently

If your application has a centralized error-handling mechanism, custom exceptions can be helpful in distinguishing different types of errors.

How to Create a Custom Exception in Java

Creating a custom exception in Java is simple. You can extend either Exception (for checked exceptions) or RuntimeException (for unchecked exceptions).

Creating a Checked Custom Exception

class InvalidAgeException extends Exception {
    public InvalidAgeException(String message) {
        super(message);
    }
}

public class CustomExceptionExample {
    public static void validateAge(int age) throws InvalidAgeException {
        if (age < 18) {
            throw new InvalidAgeException("Age must be 18 or above.");
        }
    }
    public static void main(String[] args) {
        try {
            validateAge(16);
        } catch (InvalidAgeException e) {
            System.out.println("Caught exception: " + e.getMessage());
        }
    }
}

Here,

• InvalidAgeException extends Exception, making it a checked exception.
• The constructor passes a custom message to the superclass (Exception).
• The validateAge method throws InvalidAgeException if age is below 18.
• The exception is caught in main and handled gracefully.

Creating an Unchecked Custom Exception

class DatabaseConnectionException extends RuntimeException {
    public DatabaseConnectionException(String message) {
        super(message);
    }
}

public class UncheckedCustomExceptionExample {
    public static void connectToDatabase(boolean connectionStatus) {
        if (!connectionStatus) {
            throw new DatabaseConnectionException("Failed to connect to the database.");
        }
    }
    public static void main(String[] args) {
        connectToDatabase(false);
    }
}

Here,

• DatabaseConnectionException extends RuntimeException, making it unchecked.
• No need to declare it using throws since unchecked exceptions don’t require explicit handling.
• If connectToDatabase(false) is called, an exception is thrown.

When NOT to Use Custom Exceptions

While custom exceptions in Java are useful, overusing them can lead to unnecessary complexity. Here are cases where they may not be needed:

1. When a Standard Exception Suffices

If a standard exception like IllegalArgumentException or NullPointerException properly conveys the issue, using a custom exception is redundant.

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

There’s no need for a NegativeAgeException when IllegalArgumentException works perfectly.

2. When They Add Unnecessary Complexity

If an exception doesn’t add meaningful information or handling logic, it might not be worth creating.

3. When Logging and Debugging Are Not Improved

If a custom exception doesn’t make debugging easier or doesn’t offer additional insights, it may not be necessary.

Best Practices for Custom Exceptions

1. Keep Custom Exceptions Specific — Avoid generic names like MyAppException; use names that reflect the issue, such as UserNotFoundException.
2. Extend the Right Class — Use Exception for checked exceptions and RuntimeException for unchecked exceptions.
3. Include Helpful Messages — Provide meaningful messages to help with debugging.
4. Document Your Exceptions — Ensure other developers understand when and why to use them.
5. Avoid Creating Too Many Exceptions — Use them only when they add real value.

Conclusion

Custom exceptions in Java are powerful when used appropriately. They provide clarity, enforce business logic, and enhance maintainability. However, standard exceptions should be preferred when they adequately describe an error. The key is to strike the right balance — use custom exceptions only when they genuinely improve code readability, debugging, and error handling.

When writing Java programs, handling errors is an essential part of creating robust and reliable applications. One important concept in Java’s error-handling mechanism is checked exceptions. If you’re new to Java or need a refresher, this guide will walk you through what checked exceptions are, how they work, and how to handle them effectively.

What Are Checked Exceptions in Java?

Checked exceptions in Java are a category of exceptions that must be either caught or declared in the method signature using the throws keyword. They are part of Java’s mechanism to enforce error handling at compile-time, ensuring that developers acknowledge and manage potential problems before running the program.

Unlike unchecked exceptions, which arise due to programming errors (such as NullPointerException or ArrayIndexOutOfBoundsException), checked exceptions typically indicate recoverable conditions like missing files, failed network connections, or invalid user input.

Let’s understand this with a simple example.

Imagine you are booking a flight online. There are two possible situations:

1. You enter correct details, and the ticket is booked successfully.
2. You enter an incorrect credit card number, and the system stops the booking process, showing an error.

In Java terms:

• Booking the flight successfully is like a normal method execution.
• Entering an invalid card number is like a checked exception, because the system knows this issue could happen and forces you to handle it (e.g., by showing an error message).

How Does Java Enforce Checked Exceptions?

When writing Java code, some operations have a high chance of failing, like:

• Reading a file (the file may not exist) → IOException
• Connecting to a database (the database might be down) → SQLException
• Waiting for a thread to complete → InterruptedException

Since these errors are expected, Java forces you to either:

• Handle them using try-catch
• Declare them using throws in the method signature

Let’s say we want to read a file. There’s a chance the file doesn’t exist, so Java forces us to handle this situation.

Without Handling (Compilation Error)

import java.io.FileReader;

public class CheckedExceptionExample {
    public static void main(String[] args) {
        FileReader file = new FileReader("path\data.txt"); // Compilation Error!
    }
}

Error: Unhandled exception: java.io.FileNotFoundException
 Java stops compilation because we didn’t handle the exception. Also the compiler suggests two options: the first one is to surround the code with a try-catch block, and the second is to declare the exception using the throws keyword in the method signature.

Handling with try-catch

We handle the error inside the method using try-catch:

import java.io.FileReader;
import java.io.IOException;

public class CheckedExceptionExample {
    public static void main(String[] args) {
        try {
            FileReader file = new FileReader("path\data.txt"); 
            System.out.println("File opened successfully.");
        } catch (IOException e) {
            System.out.println("Error: File not found.");
        }
    }
}

Output if file exists: File opened successfully.
Output if file is missing: Error: File not found.

Handling with throws (Delegating the Exception)

Instead of handling it inside the method, we can let the caller handle it by declaring throws in the method signature.

import java.io.FileReader;
import java.io.IOException;

public class CheckedExceptionExample {
    public static void main(String[] args) throws IOException {
        FileReader file = new FileReader("path\data.txt"); 
        System.out.println("File opened successfully.");
    }
}

This approach is useful for propagating exceptions to higher-level methods where they can be handled appropriately.

Why Are Checked Exceptions Important?

Checked exceptions serve an important role in Java by enforcing better error handling. Here’s why they matter:

1. Compile-Time Safety: They prevent runtime failures by ensuring errors are anticipated and handled during development.
2. Encourages Robust Code: Developers are forced to think about possible failure scenarios and how to deal with them.
3. Improves Code Maintainability: Explicit exception declarations make it clear which methods can fail, improving readability and maintainability.

Conclusion

Checked exceptions in Java play a crucial role in enforcing proper error handling at compile-time. By understanding how they work and following best practices, you can write cleaner, more reliable Java code. Whether you use try-catch blocks or declare exceptions with throws, handling checked exceptions properly ensures your applications run smoothly and recover gracefully from potential issues.

By integrating these techniques into your Java development workflow, you’ll be better prepared to handle unexpected situations, making your applications more robust and user-friendly.