Ad removing finalize eventually (Re: JEP 411 Headaches: Instrumenting private methods in the JDK for authorization checkpoints.
peter.firmstone at zeus.net.au
Tue Jul 27 11:24:01 UTC 2021
On 27/07/2021 8:01 pm, Rony G. Flatscher wrote:
> 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?
> 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.
More information about the jdk-dev