Re: Bug parade
(I am also often wondering that no Compile-time error is thrown if a
class implementing Serializable does not have a noargs constructor)
There is no relationship between implementation of an interface and
what constructors a class has. Interfaces cannot specify
constructors, therefore there is no interface-based restriction on
what constructors an implementing class may have.
There is also no operational requirement for a Serializable class to
have a no-arg constructor, thus it would not only be unnecessary but
harmful for lack of such to cause a compiler error.
Serialization is though a special interface... Its not there for
specifying functional behaviour but behaviour that the class can be
serialized so it would be good if this were checked ...
If you never used it, it would be nice to get a compiletime
error/warning if you defined a class that can not be deserialized as its
definately sth the compiler can know.
And till now Deserialization of classes that directly extend Object and
do not have a noargs constructor allways failed for me.
According to the Javadoc, the Serializable class itself
does not need a no-args constructor. Deserialization does
not use any of that class' constructors at all, so the lack
of a no-args constructor or an array-of-int constructor or
any other constructor is no hindrance.
However, every Serializable class eventually descends
from a non-Serializable class -- from Object, if nothing
else. And it is *that* class whose no-args constructor is
used during deserialization. Object has such a constructor,
so a Serializable direct subclass of Object should present
no difficulties. I suspect you may have misremembered the
details of the trouble you ran into.
As to whether the compiler could/should complain if your
Serializable class extends a non-Serializable that lacks a
no-args constructor -- Well, I guess it would be helpful. The
situation would have to be special-cased by the compiler, since
an interface definition can't specify constructors. But the
compiler has special cases for lots of other things already
(toString(), autoboxing, Iterable, ...), so it might not be an
enormous burden to add this one. You might want to submit an
RFE for it (or add your vote to an existing RFE if there's
already one in the database).