Issue1551

I'm trying to port our Java application that uses Jython 2.1 to use Jython 2.5.1.  However, I'm getting the following error using Jython 2.5.1 which prevents us from using it: 

  SystemError: Automatic proxy initialization should only occur on proxy classes 

I see this error after calling copy.copy or copy.deepcopy() to copy a Java type variable (such as one of type java.util.ArrayList for example).  The copy completes without any errors but as soon as the copied variable is accessed in any fashion, this SystemError occurs. 

Josh Juneau responded to my posting to the jython-user mailing list about this problem and said:

"Looks like your copied object is being treated as a proxy class and I don't think that should be happening.  The PyObject code has been completely overhauled for the 2.5.x release, and therefore it is difficult for me to look through the old code from 2.2.1 and compare...so I cannot tell you the exact cause.  This looks like a bug"

Here's a simple example of this problem after copy.copy() is used to copy a java.util.ArrayList instance, and then the copied variable is accessed.  This example works fine using Jython 2.1.   

C:\jython2.5.1>jython 
Jython 2.5.1 (Release_2_5_1:6813, Sep 26 2009, 13:47:54) 
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_13 
Type "help", "copyright", "credits" or "license" for more information. 
>>> from java.util import ArrayList 
>>> gList = ArrayList() 
>>> gList 
[] 
>>> import copy 
>>> copyList = copy.copy(gList) 
>>> copyList 
Traceback (most recent call last): 
 File "<stdin>", line 1, in <module> 
SystemError: Automatic proxy initialization should only occur on proxy classes 
>>> globals() 
Traceback (most recent call last): 
 File "<stdin>", line 1, in <module> 
SystemError: Automatic proxy initialization should only occur on proxy classes 
>>> 

Note this problem occurs with some other Java classes as well, including some custom  classes we use, not just a Java list. 

It seems to me to be a very "bad" thing as globals() also then fails with this error.  This problem prevents us from migrating our Java application to use Jython 2.5.1.

Note:  Our application is STAX which is used by thousands of poeple and is part of the STAF open source project (http://staf.sourceforge.net).  Many of our customers have requested upgrading STAX to use Jython 2.5.1 (instead of Jython 2.1) so that they can take advantage of the new Python features.  However, this bug prevents use from using Jython 2.5.1.

Please let me know if there is a workaround or fix for this bug.  Or, if I can provide any more information to help resolve this problem.  Thank you.

If you n

I am looking into this issue starting with PyObject.  It seems that java libraries shouldn't be treated as proxy classes and for some reason a copy  of such an object is being treated as such.

A workaround to make shallow copies of native Java objects is to use the Java clone() technique.  In order to repair this issue and ensure that the Jython interpreter does not treat copies of native Java objects using copy.copy as proxy classes, we'll have to somehow alter the proxy objects (or perhaps the copy lib) to perform a check to see if indeed the object being copied is a native Java object.  If it is a native Java object, then treat differently then a Python object that inherits from a Java class.  

Perhaps the easiest fix would be to place a check in the copy lib that would simply use clone() as opposed to copy.copy if an object is found to be a native Java object.  The most difficult part of the problem is determining if an object is indeed native Java or a Python class that inherits from a Java object.

As I mentioned in my email to jython-dev, you can determine whether something is a java object via isinstance(obj, java.lang.Object) and whether a type is a java class via issubclass(cls, java.lang.Object)

I've re-implemented copy.py so that it makes use of the clone() technique to create shallow copies of Java objects.  It now also has a java deep copy implementation.  Lastly, a function is_java(obj) has been included to help differentiate java objects from python.  This implementation of copy.py is fully functional.  However, it appears that copy.py in general needs to be optimized.  There is currently some development work towards implementing copy.py in java...this should help optimization.