S2975: For a final class, it should be allowed to leave out super.clone()

[davidsusu (Dávid Horváth)]

@xfix

Generic context doesn’t work because Cloneable interface doesn’t have clone method.

Right. However, someone could have a subinterface that extends pure Cloneable.

@xfix

Even if generic context did work, the clone contract requires that x.clone() != x which means that immutable objects don’t implement Cloneable (as doing so would encourage wasteful copying).

I don’t want to inherit immutable objects from Cloneable.

@xfix

You don’t need to implement Cloneable if you want a clone method in your object. Implementing Cloneable interface is only necessary if you want to use super.clone() .

This is your best argument against using Cloneable without using super.clone(). I would allow it anyway.

@xfix

Having code where method chaining with clone() method makes the code cleaner compared to clone constructor likely violates Law of Demeter.

Right. However, I am not an unconditional fan of LoD because of its reverse coupling and vertical chaining traps.

@xfix

About semanticness/explictiness of clone method, I would argue that having a clone constructor (a constructor that accepts an object of its own class) is more common in Java code.

It’s probably true. But I am trying to minimize the number of constructor calls outside of factories.