Runtime Type Identification

There are two main tools. The instanceof operator tests whether an object is an instance of a type, including its subtypes, and it is the one you normally want. The getClass method returns the object's runtime class object, from which you can read the simple name or compare class references with the equality operator.

public class Main {
    public static void main(String[] args) {
        Object o = "hello";
        System.out.println(o.getClass().getSimpleName());
        System.out.println(o instanceof String);
        System.out.println(o instanceof Integer);
        if (o instanceof String) {
            String s = (String) o;
            System.out.println(s.length());
        }
    }
}

The output shows the difference between the two questions you can ask. The class name tells you precisely what the object is: String. The instanceof checks tell you what it is compatible with: true for String and false for Integer, because a string is not a number.

The narrowing cast after the check is safe because the instanceof test proved it. The compiler understands that inside the branch the reference really is a string, so the cast cannot fail. Without the check, the same cast would be a risk that surfaces at run time as a class cast exception.

There is a third way, and it is the one to avoid: reading the class name as a string and comparing it. That breaks the moment someone subclasses the type you were matching, because the name is different even though the behaviour is compatible. Comparing class references is better than comparing names, and instanceof is better still.

Because a type check inside a method means the method has to know about every type it might receive, and that set of types has to be updated whenever a new one arrives. The method that handles the general case now contains a switch on the concrete types, which is exactly the branching that polymorphism was supposed to remove.

It also inverts the dependency. The caller of a general type ends up depending on the specific subclasses, so the abstraction leaks in both directions and the hierarchy can no longer be extended without touching the code that consumes it.

The better design is to move the decision to where the knowledge already lives. If the code needs to do something specific to a circle, give the shape type a method for it, or introduce an interface that expresses the capability being needed and let the classes that support it implement it.

Runtime type checks are not always wrong. They are reasonable when the set of types is genuinely closed and known, when you are bridging to an external library with its own type model, or when you are dispatching to genuinely different algorithms. But in an open system, they are a signal that the contract is missing a method.