> bazillion ordering rules

There are 3 which pertain to object initialization in Java.

1. super is initialized in it's entirety by an implicit or explicit call to `super()`

2. All instance initializers of the present class are invoked in textual order.

3. Constructor code following the `super()` call is executed.

The only awkward thing here is the position of #2 in between #1 and #3, whereas the text of a constructor body suggests that #1 and #3 are consecutive. It gets easier to remember when you recognize that, actually, there's a defect in the design of the Java syntax here. A constructor looks like a normal function whose first action must be a `super()` call. It's not. The `super()` call is it's own thing and shouldn't rightly live in the body of the constructor at all.

Edit: Tweaks for clarity.

Those are the normal issues inherent to constructors as a concept (except for the finalizer one).

Any language that has constructors has some complex rules to solve those things. And it's always good to check what they are when learning the language. Java has one of the simplest set of those rules that I know about.

> - Java constructors can return the object before they complete construction, finishing at a later time; this is visible in concurrent code as partially constructed objects > > - Java constructors can throw exceptions and return the partially constructed object at the same time, giving you references to broken invalid objects

Java constructors do not actually return the object. In Java code, it would appear to the caller as though the contructor returns the new instance, but that is not really the case. Instead, the new object is allocated and then the constructor is called on the object in (almost) the same manner as an instance method.

Additionally, Java constructors can only leak a partially initialized object if they store a `this` reference somewhere on the heap (for example, by spawning a thread with a reference to `this`). The assertion that this gives you a reference to a "broken invalid object" is only potentially correct from the perspective of invariants assumed by user-written code. It is perfectly valid and well-defined to the JVM.

> - Just.. all the things about how calling super constructors and instance methods interleaved with field initialization works and the bazillion ordering rules around that

This is a gross mischaracterization of the complexity. There is only a single rule that really matters, and that is "no references to `this` before a super constructor is called". Until very recently, there was also "no statements before a super constructor is called".

> - Finalizers in general and finalizers on partially constructed objects specifically

Finalizers are deprecated.

I think you’re exaggerating the complexity here. There are corner cases yes, but the compiler will warn you about them.

    > Java constructors can throw exceptions and return the partially constructed object at the same time

Can you show some sample code to demonstrate this issue?