...
One commonly suggested solution is to place code at each point where the superclass can be instantiated to ensure that the instance being created has the same type as the superclass. When the type is found to be that of a subclass rather than the superclass' type, the checking code performs a security manager check to ensure that malicious classes cannot misuse the superclass. This approach is insecure because it allows a malicious class to add a finalizer and obtain a partially-initialized instance of the superclass. This attack is detailed in guideline "OBJ05-J. Do not allow Prevent access to partially initialized objects."
...
Unfortunately, throwing an exception from the constructor of a non-final class is insecure because it allows a finalizer attack. (See guideline "OBJ05-J. Do not allow Prevent access to partially initialized objects".)
...
This compliant solution invokes a security manager check as a side-effect of computing the boolean value passed to a private constructor (as seen in guideline "OBJ05-J. Do not allow Prevent access to partially initialized objects"). The rules for order of evaluation require that the security manager check must execute before invocation of the private constructor. Consequently, the security manager check also executes before invocation of any superclass' constructor. Note that the security manager check is made without regard to whether the object under construction has the type of the parent class or the type of a subclass (whether trusted or not).
...