Callback object referencing outer class methods

If an callback object is passed to an event handler how contained class methods and properties are accessible within the callback class definition, for example in the below code

class HomeFragment : Fragment() {
...
private fun showAlert(msg: String) {
AlertDialog
.Builder(context)
.setMessage(msg)
.show()
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
button_update.setOnClickListener {
showAlert("Sample")
}
}
//    or the one below
private val message = "World"
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
button_update.setOnClickListener(object: View.OnClickListener {
val message = "Hello"
override fun onClick(v: View?) {
showAlert(message)
}
})
}
....
}

showAlert is a private Member of HomeFragment, the event handler is an instance of OnClickListener interface these are two different objects but somehow the callback object is able to reference the container class method.

Two questions

1. what kind of reference the callback will hold of the outer class,
2. how the variables and methods are resolved without a need to specify any special properties

Since this pattern is common in android and I wonder how this would affect the references of the container class, and will this cause any memory leaks of any sort. For ex, similar to above code, here the callback is also a member of container class with circular reference but i have seen code with this pattern (not necessarily click handlers this is just for example)

private val handler = object: View.OnClickListener {
val message = "Hello"
override fun onClick(v: View?) {
showAlert(message)
}
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
button_update.setOnClickListener(handler)
}

Probably this is answered earlier, Only question i found is this question, but the answer only covers part of the question that is how the calling context is captured.

There are so-called 'top level types' which are types defined at the 'top level' of a source file. Then there are so-called 'inner types' which are types pretty much defined anywhere else. Specifically, either 'in types', or 'in execution contexts'. For example, Inner is an inner type in:

class Outer { class Inner {} }

and MethodInner is an inner type by way of 'inside an execution context' in:

class Outer {
void method() {
class ThisIsAMethodInner{}
}
}

method-inner classes capture state by definition. type-inner classes do so UNLESS you opt out of it, by using the static keyword.

You should always make type-inner types static*

If you make an inner type static, all you've really done is given yourself access to private stuff from your enclosing class code, and it's a namespace thing. In class Outer { static class Inner {}}, you could write anywhere else new Outer.Inner(); - Outer is a part of Inner's namespace and that's about all there is to it. Simple. Easy.

With a non-static inner, it's exactly as if:

1. There is a private and final instance field with a hidden name that you can't see, but it is there, and it is of your outer class's type.
2. All constructors that Inner has are 'upgraded' with an additional parameter, all the way at the front, of type Outer, and it is used to initialize that field.
3. The syntax to invoke those constructors is wonky. It's not newInner(outerInstance, otherParams); - no, it is outerInstance.new Inner(otherParams);
4. If there is any valid take on this available in context that would fit as outer instance, than that version of this is implied. In other words, you CAN write just new Inner() (vs. outerInstance.new Inner()), but only in places where Outer x = this; would compile.

You get allllllllll the downsides of this, and they are legion! Your inner WILL prevent garbage collection of the outer. It is IMPOSSIBLE to make instances of inner without having an instance of outer available. The generics of outer are available in inner which makes reasoning about things hard and the syntax gets very hairy very quickly. Hence why it is usually a much better idea to make any field of the outer type explicit, and make the inner type static.

When I say 'it is exactly as if', I mean it. Use javap or any other class file decompiler and you will find that what I described is literally how it works. javac makes all that stuff happen. Try it! you'll see those hidden fields and the extra parameter on all the constructors. You'll see that a ref to the outer is always passed on stack whenever the INVOKESPECIAL (which is JVM-ese for 'call a constructor') of a non-static inner is invoked.

*) Until you know enough java to know when you can disregard this rule.

NB: Note that method-local inners even capture all (effectively) final local vars declared before it, which is kinda cool, but you can't opt out of it in that context.

NB2: Anonymous inner classes, such as ClickListener listener = new ClickListener() { public void onClick(Event evt) { ... }} are a method local inner class and capture all relevant scope.