StartJVM and other upgrading issues with 0.7.0

[Thrameos]

A few common issues have appeared in upgrading between JPype 0.6.3 and 0.7.0. Some users have simply been rolling back to the 0.6.3 version, but that has a number of issues that could result in segmentation faults,

To help in making the transition here are a few of the most common problems.

startJVM

The previous version was very forgiving with regard to options passed to the JVM. As a result mistakes such as a bad -Djava.clss.path= would result in result in difficult to spot errors. To solve this issue the variable ignoreUnrecognized was exposed with the default state False. This change has exposed bugs in modules which were passing options that are not accepted by the users JVM. Running with ignoreUnrecognized=True would cause unnecessary bugs for future developers, while running with it False would rightly catch potential errors in existing modules.

Solution

Adding ignoreUnrecognized=True to the call to startJVM will make the JVM proceed even when the option is not supported by the JVM.

Deprecated StringConversion

Users will see a deprecation warning with regarding convertStrings. This is a harmless warning indicating that the Python module needs to select a policy regarding string conversions. In previous versions Java strings were automatically converted to Python strings. This was a performance issue and made portions of the Java API difficult to use. The default is still True as it was in 0.6.3 but will be changing starting from version 0.8. Thus Python libraries should select a policy during the transition period.

Solution

If the previous default behavior of converting strings is desired, then convertStrings=True should be added to the startJVM call.

Direct access to private fields

Due to a bug in 0.6.3 private variables were exposed as part of the interface. Also 0.6.3 had a default class customizer which automatically created a property to get and set if the methods matched a Java bean pattern. This property customizer was loaded late after many common java.lang classes were already loaded, and was not retroactive thus only user loaded classes that happened after initializer would have the customization. The private variable bug would mask the property customizer as the property customizer was not to override fields. Some libraries were unknowingly accessing private variables assuming they were using the property customizer.
The customizer was both unnecessary and resulted in frequent errors for new programmers. The buggy behavior has been removed and the problematic property customizer has been disable by default in 0.7.

Solution

Add lines to the module to enable the old property behavior. But this will not reenable the previous buggy access to private variables. Thus code that was exploiting the previous behavior which bypassed the getter/setter of java will need to use the reflection API.

To enable the property customizer, use

try:
   import jpype.beans
except ImportError:
   pass

Accessing Exceptions

Prior to 0.7, JPype exceptions were double wrapped. An outer wrapper as a Python exception contained an internal Java exception. The previous version used JException to catch this pattern, but some Python modules did not use this pattern by instead tested the exception arguments directly.

Solution

It is best to convert these sections to use the JPype 0.7 API in which a standard try except structure can be used to catch Java exceptions. The exact conversion for previous exception depends on the formulation that was used. Catching exceptions by catching or rethrow and catching with JException should work in both versions.

Internal changes

The underlying structure of JPype made considerable changes between 0.6 and 0.7 series. Modules which were making undocumented access to the internal module will likely be busted. Documentation of these internal changes is in Changelog-0.7.rst. Please submit a issue if there does not appear to be a good mapping between the old and the new api.

[pelson]

Looks like this issue has run its course?

FWIW, I added a PR in #1062 which makes the startJVM signature even more explicit.

[Thrameos]

Yeah it is likely safe to close this one.