Message8930

I finally decided to have finalizeTrigger in every PyInstance and removed PyFinalizableInstance. Benefits:

- It is possible for instances to acquire __del__ finalizers like in CPython

- If a class acquires a __del__ method this will be only active for instances created after the calss acquired the finalizer. Now it is possible to at least manually tell already existing instances to be finalizable:
Add to import section:
if platform.system() == "Java":
	from org.python.core.finalization import FinalizeTrigger

After a class acquired a finalizer, one can call
if platform.system() == "Java":
	FinalizeTrigger.ensureFinalizer(alreadyExistingInstance)

- CPython prior to 3.4 allows repeated object resurrection, i.e. calls finalizers again, if an object was already gc'ed, resurrected and gc'ed again. This behavior cannot be reproduced by Java automatically. So the fix behaves like CPython >= 3.4 by default. However, one can use
if platform.system() == "Java":
	FinalizeTrigger.ensureFinalizer(resurrectedInstance)
to tell Java manually that a repeated finalization is intended. This way one can fix code that depends on CPython < 3.4 behavior.


I propose to forbid PyObjects o have a finalize method.  This is done by adding a final empty implementation. This has no performance impact, since empty finalizers are optimized away. See http://www.javaspecialists.eu/archive/Issue170.html

This forces a clean use of the new finalization API. However, without this constraint everything should still work, except that one cannot fix repeated finalization manually. The real problems only arise if JyNI is used. It will cause that Java-finalizers might be called too early, i.e. when objects are still needed. This is a side-effect of its way to deal with garbage collection for extensions.

Given that an easy fix for PyObjects that need Java finalizers is available (it is explained by detailed instructions in FinalizablePyObject's javadoc) and that Jython 2.7 is a significant step, I recommend to undertake this break here.

If you should not agree, I would suggest to make it fire a compiler-warning (can anyone tell me how to do this?) stating that problems with JyNI will probably arise, if Java-finalizers are used. In that case I would recommend to forbid finalizers at least for Jython 3+ versions.


Feel free to review the patch at https://bitbucket.org/stewori/jynithon/commits/288366399aeda6832b36cc5be432a2b878d09139?at=default

It passes regrtests with no notable difference to Jython without the fix (which actually fails 25-27 regrtests on my system).

I added a new test demonstrating the new capabilities as Lib/test/test_finalizers.py

According to the patch guidelines https://wiki.python.org/jython/PatchGuidelines, I should create an svn diff file and provide it here. These guidelines appear outdated to me, which is why I created a mercurial commit in bitbucket instead. Please let me know, if the svn diff is still needed or where I can find an updated patch guide.