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
