If we have the JVM running when we define classes/interfaces we can validate the implementation there and then, rather than deferring any exception to later on.
#Jvm startup time code#
It prevents accidental use of non-imported classes which improves type safety and makes python code more robust to code refactors of the java codeĬould you provide more detail on this please I'm a little confused as JPype could/does manage the imports for us as we access names on a JPackage instance. I don't fully understand the comment in the motivating PR though: Tab completion in an IDE is also not possible.
The old jpype.JClass('') approach of accessing a class by string rather than using the import mechanism feels a little hacky, and is certainly not something that is easy to validate statically (I had an idea on that, but hit a brick wall in python/mypy#10004, more to follow). Python 3.5 was end-of-life in September 2020. Honestly, this doesn't bother me in the slightest. You could argue this is an advantage, as it is much more explict, and allows things like import aliases etc. This is a fair reflection of what you have to do in both Python and in Java, but it does indeed represent more LOC than the old mechanism. This is a fairly minor point, but in order to use something from Java using the new import system, you have to import it. I believe it is possible to create an alias/special-prefix if there is a collision you particularly want to avoid, but this mechanism seems to be undocumented (the whole of jpype.imports is undocumented currently, including registerDomain). If a registered name collides with a Python package, the Java package wins if jpype.imports is enabled (and not otherwise). This is done by opt-in, except for a few pre-registered names. The JPype import hook involves commandeering the top-level names used in Java.
JPype takes ownership of Java TLD namespaces In all honesty, this is the single reason why I'm writing this issue - I'd love to find a single solution that is workable for all types of code which use JPype. The import side-effects / order requirements alone mean that I've been unable to recommend the use of the JPype import system for anything other than end-user applications (and categorically not libraries). This is more than just a theoretical "you shouldn't do that" - it puts our code against essential development tools such linters and our helpful IDE/isort (to fix import order automatically) will actively break both examples by "fixing" our import order for us. # Works because the previous example started the JVM and enabled the ``jpype.imports`` hook.īoth examples demonstrate import side-effects (the JVM gets started!) and the import order is critical to the successful operation of the code. Unfortunately the JPype import mechanism forces us to either start the JVM in our code before importing Java packages, or to import things in a specific order such that another module has a JVM starting side-effect. I'm no Java expert, but I've seen a few Java packages in which side-effects are common (starting a background thread, initialising static members, etc.), so perhaps this is a significant cultural difference between the Python & Java languages? In Python it is frowned upon to have a major side-effect at import-time.
#Jvm startup time free#
Pros / Cons Downsides Python imports should be side-effect free & import order shouldn't matter There are some major downsides to using it though, so I wanted to open this ticket to discuss (and hopefully mitigate) them. from java.utils import Object vs Object = jpype.JClass('')). The new(ish) JPype import hook (added in #224) is a neat trick to allow us to declare Java imports in a Pythonic way rather than using string based package access (e.g.
0 kommentar(er)
