Name collision public field and method

[injo11]

With the following Java class:

public class A {
	
	public double mean;
	
	public double mean() {
		return mean;
	}
}

I only see the method mean() on the Python side, not the field, if there is a name collision. Is there any way around this (we can't see some of our public fields at the moment because of this)?

[Thrameos]

The code you are showing is certainly bad practice, but there are work arounds. JPype fully supports Java reflection to access any members that are not available in the Python space. If you just need to get one or two fields that works fine.

Alternatively, assuming your whole library contains such an idiom, you can use a customizer to automatically add conflicting symbols with an underscore.

def asProperty(field):
    def get(E):
        return field.get(E)
    def set(E, V):
        field.set(E,V)
    return property(get, set)

@jpype.JImplementationFor("java.lang.Object")  #  Use your baseclass,  as written this affects all objects.
class MyCustomizer(object):

    # This is applied to every class that derives from the type
    def __jclass_init__(cls):
        # Traverse the fields
        for field in cls.class_.getDeclaredFields():
            name = str(field.getName())
            tp = type(cls.__dict__.get(str(field.getName()), None))

            # Watch for private methods
            if tp is type(None):
                continue

            # There was a conflict between a public field and public method
            if tp is jpype.JMethod:
                cls._customize("%s_"%name, asProperty(field))

A = jpype.JClass("A")
a = A()
print(a.mean_)
a.mean_= 2
print(a.mean_)

You can customize any behavior of any Java wrapper (rename, make beans properties appear as Python properties, rearrange the class tree, etc). This is in addition to adding python methods or defining the type conversions that apply.

To get more details look over jpype/_jcollection.py which will show you how to Pythonize Java classes and jpype/beans.py which shows full customization of classes.

[Thrameos]

@marscher I could catch conflicts like this back in the class definition phase. I was surprised to see that some of the java base classes used this idiom. Is it worth making this a supported behavior? I just worry about the conflict symbols generating their own conflicts.

[marscher]

I'm wondering why this has never popped up before. It seems to be a rare (and bad practice) pattern. When we generate alternative names for conflicting members, we would need to deal with conflicts of our own - that's right. I really cannot tell, if it is worth the effort.
Maybe we could append suffixes like "_method" or "_field" and if it conflict again, we increment a number suffix (and append a note to the docstring to which Java member the Python alias is redirecting to)

[Thrameos]

Its more complex then that, In order to recognize whether we are making a conflict we would have to know from which place each symbol originated. Methods and even fields with the same name can appear at different levels of the hierarchy. For methods we would need to make sure it isn't just the same overload. Fields we can cast for I believe.

Because it is considered bad practice to use a leading underscore in the language documention by the language itself I don't think it is significant risk. If we really wanted to make symbols with no risk of interfering we could use the "$" prefix. Leading "" means private in Python and "_$" is illegal in Java (though the compiler does not actually guard against it). You have to use getattr to access it though and it would break compatibility, but that would have been the safest choice for symbols we move out of the way.

[injo11]

Thanks a lot for the suggestion with code, we are deliberately using public final field objects that manipulate properties with the same name as those fields (so not quite like in the example). So we use this pattern; if we can get the workaround to work it is all fine, great though if handled internally by jpype.