jpype v1.0.2 Release Notes

Release Date: 2020-07-31 // over 1 year ago

    The wrapper for Throwable was getting the wrapper for Object rather than
    the expected wrapper resulting in odd conversions from Python classes.

    โœ๏ธ Typos within the import system resulting in "jname" not found corrected.

    C propagates to a KeyboardInterrupt properly.

    โž• Added cache to the method dispatch to bypass resolution of overloads.
    This reduces the cost of method resolution significantly especially if
    the same overload is hit repeatedly such as during loop operations.

    ๐Ÿ‘Œ Improved speed on transfer of lists, tuples, buffers to arrays of Java
    primitives by a factor of 4 to 100 depending on the data type. The
    โšก๏ธ conversion uses optimized path for memory buffers, rather than the
    Sequence API. When a Python buffer is encountered only the
    first element is checked for conversion as Python buffers are homogeneous.

    Corrected symbol problem with Python 3.5.3. PySlice_Unpack was introduced
    ๐Ÿš€ in a later patch release and should not have been used.

    shutdown The behavior log entry for changes on shutdown were lost in
    ๐Ÿš€ the 1.0 release. JPype now calls the JVM shutdown routine which tries to
    gracefully exit when shutdown is called. This results in several changes
    in behavior. Non daemon threads can now hold open the JVM until they have
    completed. Proxy calls will hold the shutdown until the call is completed
    but will receive an interrupt message. Files now close properly and will
    ๐Ÿ‘ป flush if the threads properly handle the exception. Resource clean up
    hooks and finalizers are executed. AtExit hooks in the JVM are called as
    spawned threads. Automatic attachment of threads by use of the JVM from
    Python are done as daemon but can be reattached as user threads on demand.
    ๐Ÿ› Buggy code that fails to properly handle thread clean up will likely hang
    ๐Ÿ“š on shutdown. Additional documentation is located in the user guide.

    A bug was reported with numpy.linalg.inv resulting in crashes. This was
    traced to an interaction with threading between the JVM and some compilations
    โ†ช of numpy. The workaround appears to be calling numpy.linalg.inv prior to
    starting the JVM.

    special note To all our friends on opennet.ru, please blame not the translator. Translating my mangled English diction and word order is torture enough. Dyslexics of the world untie!