Type Safety Without Explicit Casting: Building a Custom Generic Stack in Java

DHRUV AHIR — Sat, 19 Sep 2026 01:01:59 +0000

Before Java 5 introduced generics, collections and data structures relied on raw Object references. While this allowed containers to hold any reference type, it deferred type checks to runtime, creating recurring risks of ClassCastException bugs.

The Pitfall of Storing Raw Objects

Consider a traditional stack built on Object[]:

ObjectStack stack = new ObjectStack();
stack.push("Active Connection");
stack.push(1024); // Accidental mismatch accepted without compiler warnings

String connection = (String) stack.pop(); // Throws ClassCastException at runtime

Whenever an element is popped, the developer must manually cast it. If an invalid type was inserted earlier, the program fails at runtime rather than during compilation.

Implementing a Generic Stack (`<T>`)

Generics allow a class to operate over types specified by the caller at initialization. The compiler enforces checks automatically, eliminating manual casting.

Here is a dynamic, bounded-growth generic stack:

import java.util.EmptyStackException;

public class GenericStackDemo<T> {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_CAPACITY = 10;

    public GenericStackDemo() {
        elements = new Object[DEFAULT_CAPACITY];
    }

    public void push(T item) {
        if (size == elements.length) {
            resize();
        }
        elements[size++] = item;
    }

    @SuppressWarnings("unchecked")
    public T pop() {
        if (isEmpty()) {
            throw new EmptyStackException();
        }
        T item = (T) elements[--size];
        elements[size] = null; // Prevent memory leak by clearing obsolete reference
        return item;
    }

    public boolean isEmpty() {
        return size == 0;
    }

    private void resize() {
        Object[] newElements = new Object[elements.length * 2];
        System.arraycopy(elements, 0, newElements, 0, elements.length);
        elements = newElements;
    }
}

Key Architectural Takeaways

Type Erasure Workaround: Direct generic array creation (e.g., new T[DEFAULT_CAPACITY]) causes a compile-time error because Java erases type parameters at runtime. Backing the store with Object[] and isolating the cast inside pop() safely circumvents this constraint.
Eliminating Obsolete References: Clearing the vacated slot (elements[size] = null) ensures the Garbage Collector can reclaim popped objects immediately rather than holding them in active memory.
Compile-Time Enforcement:

GenericStackDemo<String> stringStack = new GenericStackDemo<>();
stringStack.push("Dev.to");
// stringStack.push(101); // Caught by the compiler immediately

String item = stringStack.pop(); // Clean extraction with no explicit cast

Companion Code

Full runnable code is available on GitHub.

Stop Writing Clunky Finally Blocks: Clean Java File Handling with Try-with-Resources

DHRUV AHIR — Fri, 18 Sep 2026 13:19:23 +0000

When working with files,network sockets,or database connections in Java, forgetting to close a resource is one of the most common causes of memory and file-descriptor leaks.

For years,developers relied on manual cleanup inside a finally block. While it works, it leads to bloated, nested code that is prone to subtle bugs.Here is why the old way is risky, and how Java's try-with-resources solves it cleanly.

The Clunky Way: Manual Cleanup in `finally`

In older Java code, closing a stream required nested try-catch blocks inside finally:

public static void riskyRead(String filename) {
    BufferedReader reader = null;
    try {
        reader = new BufferedReader(new FileReader(filename));
        System.out.println("Reading line: " + reader.readLine());
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        try {
            if (reader != null) {
                reader.close();
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Why this is problematic:

Verbose Boilerplate: Over half the function exists just to close a single stream safely.
Suppressed Exceptions: If an exception occurs in both the try block and the finally block, the exception in finally overwrites the original error, making debugging significantly harder.

The Modern Way: `try-with-resources`

Introduced in Java 7, try-with-resources automatically handles closing any resource that implements java.lang.AutoCloseable.

Here is the exact same logic written cleanly:

public static void safeRead(String filename) {
    try (BufferedReader reader = new BufferedReader(new FileReader(filename))) {
        System.out.println("Safe reading line: " + reader.readLine());
    } catch (IOException e) {
        System.err.println("Failed to read file: " + e.getMessage());
    }
}

What happens behind the scenes:

The resource (BufferedReader) is initialized inside parentheses directly after try.
As soon as execution leaves the block—whether normally or via an exception—the JVM automatically invokes reader.close().
If both the read operation and the auto-close fail, Java preserves the original exception and attaches the secondary error via suppressed exceptions.

Complete Runnable Example

Runnable companion code available on GitHub.

Whenever you deal with I/O streams, database connections, or network sockets, verify if the class implements AutoCloseable. If it does, always wrap it in try-with-resources to eliminate resource leaks and unneeded boilerplate.

DEV Community: DHRUV AHIR