Mise à jour de JPype 1.0.2, une bibliothÚque pour accéder aux classes Java depuis Python

Disponible nouvelle version de la couche JPype 1.0.2, 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 est distribué 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

Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS đŸ”„ Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster