What Are Constructor Types in Java?

Java constructors fall into a handful of recognisable shapes. A no-argument constructor takes no parameters and initialises the object with defaults or with values you hard-code. A parameterised constructor takes arguments and uses them to set the initial state. A copy constructor takes a single argument of the same class type and copies an existing object. A private constructor blocks outside callers from creating instances, which is how utility classes and singletons enforce their rule. A static factory method is not a constructor at all, but it is the idiomatic alternative when construction needs to be validated or the type needs more than one representation.

When you declare no constructor, the compiler generates a default one for you. It has the same access as the class, it takes no arguments, and it calls the superclass no-argument constructor. Every field is left at its default value — zero, false, null — because the constructor body does nothing.

The rule that catches people out is that declaring any constructor suppresses the implicit default one. Once you write a parameterised constructor, new MyClass() no longer compiles. That is why you sometimes see an explicit no-argument constructor written alongside a parameterised one: it is not redundant, it is preserving the ability to construct the object without arguments, often because a framework needs it.

Two more constraints. The constructor name must match the class name exactly, and unlike a method it has no return type — not even void. And a constructor must be the first statement to call this or super when it needs to delegate, which is what makes constructor chaining possible.

The default constructor is generated by the compiler when you declare none. It takes no arguments, it is public if your class is public, and it leaves every field at its default value because its body is empty. It also implicitly calls the superclass's no-argument constructor, which is why a class whose superclass has no no-argument constructor cannot rely on an implicit default of its own.

The moment you write any constructor — even one that takes a single argument — the compiler stops generating the default one. From that point new MyClass() is a compile error: no constructor matching that signature exists. Many newcomers meet this as a confusing error message on a line they thought was fine, usually in a test where a framework tries to instantiate the class reflectively with no arguments.

public class Main {
    public static void main(String[] args) {
        WithDefault d = new WithDefault();
        System.out.println("default values: " + d);

        // WithExplicit declares a constructor, so there is no zero-arg one.
        // new WithExplicit();   // compile error: no matching constructor
        System.out.println("needs arguments: " + new WithExplicit("given"));
    }
}

class WithDefault {
    int count;
    String name;
    boolean flag;

    @Override
    public String toString() {
        return "count=" + count + " name=" + name + " flag=" + flag;
    }
}

class WithExplicit {
    private final String label;

    WithExplicit(String label) {
        this.label = label;
    }

    @Override
    public String toString() {
        return "label=" + label;
    }
}

The output shows the default constructor's effect: count is zero, name is null and flag is false, because the generated constructor does nothing but call the superclass. The second class needs an argument because its explicit constructor removed the implicit one.

The rule of thumb is simple: if your class has final fields, or a constructor that validates its arguments, write the constructors you want explicitly — including a no-argument one if callers might reasonably expect it. Do not rely on the compiler to generate something you never asked for.

Because a constructor's job is to bring an object into existence. Once an object exists, its identity, its state and its position in the heap are settled, and there is no legal way to say "run the constructor again on this object". The new operator always produces a new object; it can never target an existing one. That is a deliberate safety property, because re-running a constructor on a live object could leave it half-initialised.

What you can do instead is write a copy constructor — a constructor that takes an instance of the same class and produces a new object with the same contents. Java does not give you one for free, which is why the Objects class provides copyOf helpers for arrays and collections.

The naive copy constructor copies fields one by one. That is fine for immutable fields and for fields whose own copy semantics are known, but it is error-prone: add a new field later and forget to copy it, and the copy silently diverges from the original. The safer approach for a class with a mutable field is to delegate to that field's own copy method, or to use clone with a proper clone contract, or to rely on the copy constructor of the field's own type.

There is a related trap worth naming. The clone method on Object is shallow: cloning an object whose field is a mutable list gives you a new object sharing the same list, so mutating it through one reference is visible through the other. A correct deep copy has to copy the mutable parts too, which is why copy constructors that simply assign a reference are a common source of aliasing bugs.