Inheriting from Java classes doesn't work

[apalala]

Part of the problem is that JavaMetaClass.new assumes that it will always be called to create a proxy, when it will be called for every descendant class. On the same line, handling of the jclass_registry must be restricted to actual proxies. Something else I found is that the treatment of objects returned from Java is lax, which makes it impossible to pass them back to Java methods.

I can work on some of this issues in due time.

I very much like how fast jnius is at loading Java, and being able to use the latest versions of Python.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1362796-inheriting-from-java-classes-doesn-t-work?utm_campaign=plugin&utm_content=tracker%2F77133&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F77133&utm_medium=issues&utm_source=github).

[tshirtman]

Sorry for the delay, can you provide more specific (testcases?) description for each of those issues? I started some work to allow inheritance of java classes from python (using proxies), but it's not complete, however, the issues you point here seems loosely related to that, and should probably be splitted in several different issues.

[ghost]

Sorry to come into the discussion, but inheriting Java a class might not be what you need @apalala, I think that it's a better idea to wrap the Java class in a Python class like it's done in this class. It might not be obvious in the linked code because all the autoclass are done in java.py but the code is equivalent to

class MyJavaWrapperClass(AnyPythonClassOrMixin):

    def __init__(self, *args, **kwargs):
        JavaClass = autoclass('org.uber.cool.JavaClass`)
        self._my_java_object = JavaClass(*args, **kwargs)  # use double underscore to "hide" the Java object

The reasons not to inherit the Java class are:

• Java methods use Java naming conventions and looks ugly in Python code, you will most likely want to rename the methods so that they have a Python look and don't surprise other developers used to the pep8 (except if you do old twisted and old Zope code...)
• Generally, it avoids cluttering the python object dict with Java inherited methods, some Java methods have nothing nothing to do in Python bindings, they will barely be called maybe never. Wrapping the Java class make the Python class cleaner in REPL and possibly avoids dreadful calls to unsupported Java methods. Mind the fact that If you don't use the double underscore, Java methods are still easily available.
• Last but not least, there are high chances that you will have to add boilerplate code before or after the call to some Java methods, you will most likely override some Java methods in Python so that you do the proper type/class conversion or other stuff, so you end up creating a Python method for the Java method just like you would do when you wrap the Java class instead of inheriting it while still being able to A) rename the method B) keep the dict clean. Look at the methods of class Element, class Node and class Relationship in graph almost all of them has boilerplate code even if most of the time it is to make the API more Pythonic ;)

From a performance perceptive, I don't think there is any impact but @tshirtman might know better.

Another thing, wrapping Java objects works right now and really well :-)

[azergha]

Is overriding java method using python code possible for now?
What about java class inheritance?

[tshirtman]

I've spent quite a lot of time looking in this, and i had come to the conclusion that there was no practical way of doing so, short of generating java bytecode at runtime, there are libraries to do that, but that felt like adding a lot of complication to the library, and probably out of scope. Not sure about closing, but i don't think it's going to get worked on, so it wouldn't be unreasonable to mark it as wontfix.

[Juphex]

@monami7001 any progress?

[tshirtman]

that was ~4 years ago, and to my knowledge no, generating java bytecode at runtime still looks like the only option (and maybe it's not as bad as i though and we should look into that).

[Juphex]

One workaround is:

1. create separate Java project including the android.jar of the targeted android version API
2. implement the code (inheritance/overrides...)
3. export to jar
4. import in buildozer

to use it with autoclass