Just a quick comment about the finalization aspect ( as I have been thinking about this too ).
On 3 Jan 2015, at 15:36, Peter Levart <peter.lev...@gmail.com> 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. In many cases default values will be safer, but not always, e.g. port number of ‘0’ implies ephemeral port. > Is there anything in JLS that guarantees finalization for instances which > fail construction or deserialisation? "An object o is not finalizable until its constructor has invoked the constructor for Object on o and that invocation has completed successfully (that is, without throwing an exception).” [1] It is unfortunate that the way default serialization constructs objects, the j.l.Object constructor is invoked before attempting to set any fields. > 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 > deserialisation I have given this some thought too, and also think that deserialized objects should not become finalizable until after the fields have been successfully set. Whether this be an internal API, JLS change, or an extension to the “magic” serialization mechanism to invoke the first non-serializable classes no-args constructor, I’m not sure. -Chris. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6.1 > > Regards, Peter >
