nueva versión del intermediario , que permite un acceso completo de aplicaciones Python a bibliotecas de clases en lenguaje Java. Con JPype, se pueden usar bibliotecas específicas de Java desde Python, creando aplicaciones híbridas que combinan código en Java y Python. A diferencia de Jython, la integración con Java no se logra a través de la creación de una versión de Python para la JVM, sino mediante la interacción a nivel de ambas máquinas virtuales, utilizando memoria compartida. Este enfoque no solo permite lograr un buen rendimiento, sino que también proporciona acceso a todas las bibliotecas de CPython y Java. Código del proyecto bajo la licencia Apache 2.0.
Principales cambios:
- Se ha añadido una caché a las llamadas a métodos, lo que evita la resolución de sobrecargas, reduciendo significativamente el impacto en el rendimiento de la resolución de métodos, especialmente si la misma sobrecarga se llama muchas veces, como durante la ejecución de bucles.
- La transmisión de listas, tuplas y búferes a arrays de primitivas Java se ha acelerado entre 4 y 100 veces, dependiendo del tipo de datos. La conversión utiliza un procesamiento optimizado de búferes en memoria, en lugar de la API de secuencias. Cuando se encuentra un búfer de Python, solo se verifica el primer elemento para la conversión, ya que esos búferes son homogéneos.
- El manejo de operaciones de apagado (implementado ya en JPype 1.0.0, pero omitido al preparar la lista de cambios). JPype ahora llama al procedimiento de apagado de la JVM, que intenta realizar la salida de manera 'graceful'. Esto conlleva varios cambios en el comportamiento. Los hilos en segundo plano (llamada proxy) ahora pueden mantener la JVM abierta hasta que terminen. Las llamadas Proxy manejarán el apagado hasta que se complete la llamada, pero recibirán un mensaje de interrupción. Los archivos ahora se cierran correctamente y se vacían en el disco (flush), si los hilos manejan la excepción adecuadamente. Se ejecutan ganchos de limpieza de recursos y finalizadores. Al generar hilos, se llaman a los ganchos AtExit. A través de un demonio, se implementa la unión automática de hilos al usar la JVM desde Python. Un código erróneo que no puede manejar correctamente la limpieza del hilo probablemente se congelará al realizar el apagado. La documentación adicional se encuentra en la guía de usuario.
- El wrapper para Throwable estaba obteniendo un wrapper para Object en lugar del resultado esperado, lo que provocaba transformaciones extrañas de las clases de Python.
- Se corrigieron errores tipográficos en el sistema de importación que llevaban al error '»jname» no encontrado'.
- Se aseguró la correcta propagación de «^C» en KeyboardInterrupt.
- Se solucionó el problema con los caracteres de Python 3.5.3. PySlice_Unpack fue introducido en la siguiente versión de parche (3.5.4) y no debería haberse utilizado.
- Se resolvió un error con numpy.linalg.inv que provocaba caídas. El problema se rastreó hasta la interacción de hilos entre la JVM y algunas variantes de numpy. La solución propuesta es llamar a numpy.linalg.inv antes de iniciar la JVM.
Fuente: opennet.ru
