On 01/03/2015 09:36 AM, Peter Levart wrote:
On 01/03/2015 01:38 PM, Peter Firmstone wrote:
> Hi,
>
> I would like to know what are the potential issues with simple
> constructor chaining where each constructor checks the invariant of its
> class state (with the already initialized state of superclass(es)).
Finalizer attack; a subclass can override the finalize method and
receive a thread of execution, even when it hasn't gotten hold of a
reference during construction. It's best to prevent an object's
construction, by throwing any exceptions before Object's default
constructor is called.
As Brian points out, this scheme can only validate intra-class
invariants. It can't validate class-against-subclass state. And, the
finalize() method will be called anyway - although this time with fully
uninitialized instance (all fields default values). If this is safer,
then alright.
Is there anything in JLS that guarantees finalization for instances
which fail construction or deserialization? Wouldn't it be better to
"register" for finalization just those instances that complete their
construction or deserialization normally? I'm just trying to understand
why it is the way it is.
Would something like this prevent Finalizer attacks?
- leave finalization registration the way it is (at object allocation
time).
- provide internal API with which a previously registered object can be
de-registered
- deserialization infrastructure de-registers the instances that fail
deserialization
How about simply forbidding classes with finalizers from being
serialized or deserialized with this mechanism? Finalizers never really
work the way you want anyway.
Seems a better option than essentially doubling (or more) the end-user
complexity to me.
--
- DML
