Does it make sense to write default constructor when it has no arguments, empty body and no other constructors exist?
The only benefit I can think of is reducing the risk of forgetting to add the default constructor when another one is created. But this error would show up anyway if the default constructor is actually being used (at least if the class is "internal" and not in a library), and if it isn't used it can be omitted (yagni).
What benefit can this have?
There is no benefit unless you are interacting with a tool or framework that detects your class's declared methods and constructors via reflection and then silently does different things depending on whether it finds the default constructor or not. (I seem to remember that early versions of Spring or Hibernate did this.)
Otherwise, as you say, any inconsistency would be flagged by the compiler, so there is no point in declaring things that would be auto-generated anyway.
// No-args constructor required by *framework*. Helps cut down on confusion later.
– Michael K
Jan 10 '14 at 13:54
The only benefit I can foresee is that you can add specific documentation to this constructor, for instance to describe how to deal with the object after instantiation, etc...
In any other case, I do not think it is useful.
But this error would show up anyway if the default constructor is actually being used (at least in the class is "internal" and not in a library), and if it isn't used it can be omitted (yagni).
Xml deserialization. Yes the error would show up, but quite late - as an exception in runtime.
