Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.

[Rony G. Flatscher]

Ad Alan's remark about eventually removing finalize in this thread:

On 25.07.2021 16:44, Alan Bateman wrote:

... cut ...
>
> That said, there is strong desire to eventually remove finalization too. Finalization was
> deprecated several years ago and the Java platform defines APIs that provide much more flexible
> and efficient ways do run cleanup actions when an object becomes unreachable. So another
> multi-year/multi-release effort to remove a problematic feature, just nothing to do with this JEP.
... cut ...

A question: what alternatives are you thinking of?

Background of the question: in an ooRexx-Java bridge for each Java object an ooRexx peer object gets
created and needs to exist as long as the Java object exists. Once the Java object gets garbage
collected the ooRexx peer object needs to be freed as well. The bridge between ooRexx (an
interpreted, message based, dynamically typed language) and Java is realized via JNI. Currently
(actually since 20 years) on the Java side the finalize method gets employed to signal to ooRexx
that its ooRexx peer object needs to be removed.

So when you think of removing finalize and think of replacements for it, is there already a
replacement devised which can be used for determining that a Java "object became unreachable"/is not
referred to anymore/about to be garbage collected (or not being interacted with anymore for good)
and be able to communicate that fact/event? What would that be? Are there already discussions, ideas
about this somewhere?

---rony

P.S.: I remember the comment back then that finalize although deprecated for use (not for removal)
for Java programs will not be removed as such use cases as described above need to use it.