nouvelle version de la couche , permettant un accès complet des applications Python aux bibliothèques de classes en Java. Grâce à JPype, il est possible d'utiliser des bibliothèques spécifiques à Java à partir de Python, créant ainsi des applications hybrides qui combinent du code Java et Python. Contrairement à Jython, l'intégration avec Java ne nécessite pas de créer une variante de Python pour la JVM, mais se fait par l'interaction entre les deux machines virtuelles, utilisant la mémoire partagée. L'approche proposée permet non seulement d'atteindre de bonnes performances, mais aussi d'accéder à toutes les bibliothèques de CPython et Java. Le code du projet sous licence Apache 2.0.
Principales modifications :
- L'appel de méthodes a été amélioré avec un cache permettant d'éviter la résolution des surcharges, ce qui réduit considérablement l'impact sur les performances de la résolution des méthodes, en particulier si la même surcharge est appelée plusieurs fois, comme lors de l'exécution de boucles.
- La transmission de listes, de tuples et de tampons vers des tableaux de primitives Java est accélérée de 4 à 100 fois, selon le type de données. La conversion utilise un traitement optimisé des tampons en mémoire, au lieu de l'API Sequence. Lorsque le tampon Python est rencontré, seul le premier élément est vérifié pour la conversion, car les tampons de données sont homogènes.
- Le traitement des opérations d'arrêt (implémenté dès JPype 1.0.0, mais omis lors de la préparation de la liste des changements) a été amélioré. JPype appelle maintenant la procédure d'arrêt de la JVM, qui tente de quitter en douceur. Cela entraîne plusieurs modifications de comportement. Les threads en arrière-plan (appel proxy) peuvent maintenant maintenir la JVM ouverte jusqu'à ce qu'ils soient terminés. Les appels Proxy traiteront l'arrêt tant que l'appel n'est pas terminé, mais recevront un message d'interruption. Les fichiers se ferment correctement et les données sont vidées sur le disque (flush) si les threads traitent l'exception comme il se doit. Des crochets de nettoyage des ressources et des finalisateurs sont exécutés. Lors de la création de threads, les crochets AtExit sont appelés. Par l’intermédiaire d’un démon, une jonction automatique des threads est mise en œuvre lors de l'utilisation de la JVM depuis Python. Le code erroné qui ne peut pas gérer correctement le nettoyage des threads risque de se bloquer lors de l'arrêt. Une documentation supplémentaire se trouve dans le guide d'utilisation.
- L'enveloppement pour Throwable a reçu un enveloppement pour Object au lieu du résultat attendu, ce qui a créé des conversions étranges depuis les classes Python.
- Des fautes de frappe dans le système d'importation ont été corrigées, ce qui entraînait l'affichage de l'erreur '»jname» not found'.
- Correction de la propagation correcte de '^[C]' dans KeyboardInterrupt.
- Un problème avec les symboles de Python 3.5.3 a été résolu. PySlice_Unpack a été introduit dans la prochaine version de correctif (3.5.4) et ne devait pas être utilisé.
- Une erreur avec numpy.linalg.inv, qui causait un plantage, a été résolue. Le problème a été attribué à l'interaction des threads entre la JVM et certaines variantes de numpy. La solution proposée est d'appeler numpy.linalg.inv avant de démarrer la JVM.
Source : opennet.ru
