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

[Rony G. Flatscher]

Hi Roger,

On 27.07.2021 15:49, Roger Riggs wrote:
> Also take a look at the java.lang.ref.Cleaner
> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/Cleaner.html>[1] added
> to in JDK 9.
> It is designed as a replacement for finalization; it uses the PhantomReferences to register
> cleanup actions.

thank you very much for this pointer too!

Currently, I have a need to keep the ooRexx-Java bridge at Java 1.6 as the baseline (which will
increase over time to Java 9, but this may very well take years judging how "overlong" some
companies keep running fully amortized systems). [The bridge still takes advantage of newer Java
versions, if necessary, e.g. the needed runtime reflection is carried out with java.lang.reflect,
starting with Java 8 with java.lang.invoke instead.]

---rony


>
> On 7/27/21 9:42 AM, Rony G. Flatscher wrote:
>> Peter,
>>
>> On 27.07.2021 13:24, Peter Firmstone wrote:
>>> PhantomReference
>>>
>>> like this:
>>>
>>> https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-collections/src/main/java/org/apache/river/concurrent/ReferenceProcessor.java
>>>
>>>
>> thank you very much for the pointer!
>>
>> ---rony
>>
>>> 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?
>>>>
>>>> ---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.