Leaking this (in the constructor) of the object itself
I understand from other questions here on SO how a leak this
could be unsafe if another object ever gets the ability to use an object that is still under construction (the one we leaked) in both single-threaded and multi-threaded environments.
My question is, what if I was leaking an object to myself ?
public Category(int id, String name) {
this.id = id;
this.name = name;
this.idPadre = this;
}
Note that on the last line of the constructor, I am leaking the object. This will usually be unsafe, as the constructor can be inherited and used with a super()
lot of code following the execution of the parent class constructor (I wrote this), thus making the leaky line not the last line of the construction process.
However, if the inheriting class is still in its constructor, then even if it leaks over the object being created, and more lines of code follow the leaking line, would it still be unsafe given that the only context that can access the leaked object is the constructor of an object (which hasn't finished executing yet)?
The question also applies to multi-threaded environments. I'm pretty sure it will be thread safe as the object leaks in on its own (one of its fields) and the fields cannot be accessed until the constructor completes. Since a constructor can access a leaky object, a constructor only works on one thread, so it must be thread safe (if it's also safe in the aspect that the first part of this question refers to).
I want to ask this question in general terms. But here is the context in which I found this event. Class is an entity class that I am storing in a relational database using ORMLite. A database table has a column whose value points to the parent of that category. If there is no parent in the category, it is itself the parent (the value of the idPadre column is the same as the value of the column ID). When writing an entity class with ORMLite annotations, this means that the entity has a reference to itself. The use of ORMLite and my desire to keep all entity classes as simple as possible are the reasons why I am not inclined to solve this with a factory method first.
source to share
When you assign this
to a field idPadre
, you can access the object if you already have an object reference to access the field. In other words, you haven't missed anything that hasn't already been missed by the calling constructor, so to speak.
A leak this
usually means leaking an object reference from a constructor before the constructor completes. The problem with the leaked this
constructor is that the fields may not have been initialized correctly. This is not a problem in this case, since you can only access idPadre
after the constructor has completed (unless you already skipped it this
earlier in the constructor), but you already missed it this
!)
If idPadre
it was a static field, then this would indeed be a leak this
, as other threads can access the static fields at any time.
source to share