Skip to content

JPype 1.0.2
Compare
Choose a tag to compare
@Thrameos Thrameos released this 31 Jul 13:42
v1.0.2
a95daf8

  • 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!

Assets 24
Loading