Pyjnius: L'héritage des classes Java ne fonctionne pas

Créé le 22 août 2012  ·  7Commentaires  ·  Source: kivy/pyjnius

Une partie du problème est que JavaMetaClass. new suppose qu'il sera toujours appelé pour créer un proxy, lorsqu'il sera appelé pour chaque classe descendante. Sur la même ligne, la gestion du jclass_registry doit être limitée aux proxys réels. Une autre chose que j'ai trouvée est que le traitement des objets renvoyés par Java est laxiste, ce qui rend impossible leur retransmission aux méthodes Java.

Je peux travailler sur certaines de ces questions en temps voulu.

J'aime beaucoup la rapidité avec laquelle jnius charge Java et la possibilité d'utiliser les dernières versions de Python.

Vous voulez soutenir ce problème ? Publiez une prime dessus ! Nous acceptons les primes via Bountysource .

enhancement

Tous les 7 commentaires

Désolé pour le retard, pouvez-vous fournir une description plus précise (cas de test ?) Pour chacun de ces problèmes ? J'ai commencé un travail pour permettre l'héritage des classes Java à partir de python (en utilisant des proxys), mais ce n'est pas complet, cependant, les problèmes que vous signalez ici semblent vaguement liés à cela, et devraient probablement être divisés en plusieurs problèmes différents.

Désolé d'entrer dans la discussion, mais hériter d'une classe Java n'est peut-être pas ce dont vous avez besoin @Apalala , je pense que c'est une meilleure idée d'envelopper la classe Java dans une classe Python comme c'est fait dans cette classe . Ce n'est peut-être pas évident dans le code lié car toutes les classes automatiques sont effectuées dans java.py mais le code est équivalent à

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

Les raisons de ne pas hériter de la classe Java sont :

  • Les méthodes Java utilisent les conventions de nommage Java et ont l'air moche dans le code Python, vous voudrez probablement renommer les méthodes afin qu'elles aient un aspect Python et ne surprenez pas les autres développeurs habitués au pep8 (sauf si vous faites du vieux tordu et du vieux Zope code...)
  • Généralement, cela évite d'encombrer le dict d'objet python avec des méthodes héritées de Java, certaines méthodes Java n'ont rien à faire dans les liaisons Python, elles seront à peine appelées peut-être jamais. L'encapsulation de la classe Java rend la classe Python plus propre dans REPL et évite éventuellement des appels redoutables à des méthodes Java non prises en charge. Gardez à l'esprit que si vous n'utilisez pas le double trait de soulignement, les méthodes Java sont toujours facilement disponibles.
  • Enfin, il y a de fortes chances que vous deviez ajouter du code passe-partout avant ou après l'appel à certaines méthodes Java, vous remplacerez très probablement certaines méthodes Java en Python afin que vous fassiez la bonne conversion type/classe ou d'autres choses , vous finissez donc par créer une méthode Python pour la méthode Java comme vous le feriez lorsque vous encapsulez la classe Java au lieu d'en hériter tout en pouvant A) renommer la méthode B) garder le dict propre. Regardez les méthodes de class Element , class Node et class Relationship dans le graphique presque toutes ont du code passe-partout même si la plupart du temps c'est pour rendre l'API plus Pythonique ;)

Du point de vue des performances, je ne pense pas qu'il y ait d'impact, mais @tshirtman le sait peut-être mieux.

Autre chose, l'encapsulation d'objets Java fonctionne en ce moment et très bien :-)

Est-il possible de remplacer la méthode Java à l'aide de code python pour le moment?
Qu'en est-il de l'héritage de classe Java ?

J'ai passé pas mal de temps à chercher là-dedans, et j'étais arrivé à la conclusion qu'il n'y avait aucun moyen pratique de le faire, à moins de générer du bytecode java au moment de l'exécution, il existe des bibliothèques pour le faire, mais cela ressemblait à ajouter beaucoup de complications pour la bibliothèque, et probablement hors de portée. Je ne suis pas sûr de la fermeture, mais je ne pense pas que cela va être travaillé, il ne serait donc pas déraisonnable de le marquer comme non résolu.

@ monami7001 des progrès ?

c'était il y a environ 4 ans, et à ma connaissance non, générer du bytecode java au moment de l'exécution semble toujours être la seule option (et peut-être que ce n'est pas aussi grave que moi et nous devrions nous pencher là-dessus).

Une solution de contournement est :

  1. créer un projet Java séparé, y compris le android.jar de l'API de la version Android ciblée
  2. implémenter le code (héritage/overrides...)
  3. exporter vers un pot
  4. importer dans buildozer

pour l'utiliser avec autoclass

Cette page vous a été utile?
0 / 5 - 0 notes