Runtime error when moving from 1.5.2 to 1.6.0

[mxufc29]

First time using jpype. I experienced a runtime failure when JPype1 upgraded from 1.5.2 (my dev environment) to 1.6.0 (clean virtual environment for testing). Managing dependencies with Poetry.
Under 1.6.0, jpype.startJVM() reports “Can’t find org.jpype.jar support library” despite the JAR being present in site-packages. Under 1.5.2, the exact same code and setup worked without issue. For now, decided to pin JPype1 to <1.6.0 which I hope restores functionality, but any guidance/insights/best practices into the updated behavior in 1.6.0 would be appreciated. Below is the code in my init file in which I preload the jpype configs.

import jpype
import jpype.imports
from tabula.backend import jar_path

jpype.addClassPath(jar_path())
if not jpype.isJVMStarted():
    jvmpath = jpype.getDefaultJVMPath()
    java_opts = ["-Dfile.encoding=UTF-8", "-Xrs"]
    jpype.startJVM(jvmpath, *java_opts, convertStrings=False)

[MkKiefer]

I got the same issue after updating to 1.6.0:

Traceback (most recent call last):
  File "/project/__main__.py", line 92, in <module>
    jpype.startJVM(jvm_path, DUMP, PERFORMANCE_CNT, MEM_MAX)
  File "/project/.venv/lib/python3.12/site-packages/jpype/_core.py", line 357, in startJVM
    _jpype.startup(jvmpath, tuple(jvm_args + extra_jvm_args),
RuntimeError: Can't find org.jpype.jar support library

[Thrameos]

As stated in the other thread on this topic, Java 1.8 can no longer be supported with JPype. Either upgrade the Java version or pin to 1.5.2. Basical Java 24 (see the other thread on versions) will force us to convert to a module meaning that we must change our core, and Java 1.8 will not support the API required for that change. Meaning either we stop supporting Java versions going forward or we have to stop supporting a very old version of Java. While Oracle can offer to support for a product that hit end of life in 2019, we can’t really do so.

[mxufc29]

Great thanks for clarifying. which java version/range do you recommend for compatibility -- only 24 and on?

[Thrameos]

Today’s situation, JPype will remain compatible with 11 on for as long as Java doesn’t pull our data model. It is still buildable for 9, 10 but for those just don’t appear on build clouds. 1.8 is currently buildable locally but will not be after this version of JPype. I always recommend sticking with a LTS. https://www.oracle.com/java/technologies/java-se-support-roadmap.html Future, I recommend for all current work use 17, 21, 25 (upcoming). We will be pinning our build system to 11 for now, but we will shift to 17 if 25 was found to require a core change. (based on current Java evolution we likely can stay pinned for at least 5 years, but the crystal ball is still rather hazy.) I know it seems like we are abandoning people, but for comparison Pythons last 2.7.18 was in 2020 and it is long dead. Holding software to the capabilities from April 2019 which was the last public release of Java 1.8 has a cost that we will loss the ability to support the last starting in September!

[petrushy]

I would propose to add a warning runtime if a too old java version is being used. I can add that to my application that uses jpype, but I think it would be best if it is part of jpype itself in case of changes etc?

[marscher]

@petrushy I'd agree that a RuntimeError etc. should be raised, if the Java version is too old - patches appreciated.

[Thrameos]

I will be finally out of current work crisis next week (and underemployed). Hopefully I will be able to add the detection code and finish the new memory model. Unfortunately no one at Python development team has given me any feedback on any of my upstream PR so we are going to be flying blind on next development cycle.

[marscher]

That's too bad nobody responding. Have you tried pinning Mr Victor Stinner?

[Thrameos]

I am guessing I was too enthusiastic and bugged them too much. I figured out a way to solve the Python/Java GC and redo our model to be safer. The problem with the first is that I initially believed I had identified a standard, though obscure, method, but it turned out to be an entirely novel solution. This led to several months of complications locally, as I was required to disclose the discovery to my employer for evaluation and potential intellectual property protection. Also that means that I was also forced to “prove” the method which is challenging as correctness is required CALM theory and a number obscure theorems that I simply have no one in my organization that can assist me with. The second still requires some dirty hacks to Python that are never going to be acceptable. Until they are willing to refactor their object model rather than hacking one piece in random places I will always need to slide the data into some place safe-ish. Once I get those dealt with I can complete the full Java reverse bridge. On the side, I am having the review of the full webfx (Python<->JavaFX<-> Javascript/HTML/CSS stack) that I developed in house. It has proven to be a real winner here for physicists because it is full and direct async access to callbacks. Hopefully I can get them all in during my Oct to Dec work period.

…

--- from webfx import * import asyncio import random import time COLORS = ["red", "green", "blue", "orange", "purple", "teal", "magenta"] def sync_no_args(): print("got sync_no_args") return "red" def sync_one_arg(arg): print("got sync_one_args", arg[0]) return "green" def sync_two_args(arg0, arg1): print("got sync_two_args", type(arg0), type(arg1), arg0, arg1) return "blue" async def async_no_args(): print("got async_no_args") return "red" async def async_one_arg(arg): print("got async_one_args", type(arg)) sys.stdout.flush() print(arg) return "green" async def async_two_args(arg0, arg1): print("got async_two_args", type(arg0), type(arg1)) return "blue" def sync_gen_no_args(): for _ in range(5): color = random.choice(COLORS) print("sync_gen_no_args yield", color) yield color def sync_gen_one_arg(n): for _ in range(n): color = random.choice(COLORS) print(f"sync_gen_one_arg({n}) yield", color) yield color def sync_gen_two_args(a, b): for _ in range(a): color = random.choice(COLORS) print(f"sync_gen_two_args({a}, {b}) yield", color) yield f"{color}:{b}" def give_list(): return ("red", "green", "blue") async def async_gen_no_args(): print("got async_gen_args") for _ in range(5): await asyncio.sleep(0.2) color = random.choice(COLORS) print("async_gen_no_args yield", color) yield color async def async_gen_one_arg(n): print("got async_gen_on_arg", n) for _ in range(5): await asyncio.sleep(0.2) color = random.choice(COLORS) print(f"async_gen_one_arg({n}) yield", color) yield color async def async_gen_two_args(a, b): print("got async_gen_two_args", a, b) for _ in range(5): await asyncio.sleep(0.2) color = random.choice(COLORS) print(f"async_gen_two_args({a}, {b}) yield", color) yield f"{color}:{b}" async def get_color(): # Simulate async work (e.g., fetch, compute) await asyncio.sleep(0.5) return random.choice(COLORS) class ManualStreamer: def __init__(self, js_handle, *args): self.js_handle = js_handle self.js_args = args self.running = True def feed(self, data_iterable): try: self.js_handle.next("red") time.sleep(1) if self.js_handle.isCanceled(): return self.js_handle.next("green") time.sleep(1) if self.js_handle.isCanceled(): return self.js_handle.next("blue") if self.js_handle.isCanceled(): return self.js_handle.resolve(None) except Exception as ex: self.js_handle.reject(str(ex)) def cancel(self): self.running = False def start_stream(handle, args): streamer = ManualStreamer(handle, *args) threading.Thread(target=streamer.feed, args=(range(10),)).start() def pre_start(context): # Bind the Python async function to JS as window.getColor window = context.window for i in range(100): window.console.log("FOO") window.sync_no_args = sync_no_args window.sync_one_arg = sync_one_arg window.sync_two_args = sync_two_args # These are now async copies window.bound_sync_no_args = as_async(sync_no_args) window.bound_sync_one_arg = as_async(sync_one_arg) window.bound_sync_two_args = as_async(sync_two_args) window.async_no_args = async_no_args window.async_one_arg = async_one_arg window.async_two_args = async_two_args # --- Synchronous generators (stream as async iterable in JS) --- window.sync_gen_no_args = as_async_gen(sync_gen_no_args) window.sync_gen_one_arg = as_async_gen(sync_gen_one_arg) window.sync_gen_two_args = as_async_gen(sync_gen_two_args) # --- Async generators --- window.async_gen_no_args = as_async_gen(async_gen_no_args) window.async_gen_one_arg = as_async_gen(async_gen_one_arg) window.async_gen_two_args = as_async_gen(async_gen_two_args) # This should make no difference ( Just testing binding, no need for html side testing) window.bound_async_no_args = as_async(async_no_args) window.bound_async_one_arg = as_async(async_one_arg) window.bound_async_two_args = as_async(async_two_args) window.give_list = as_async_gen(give_list, delay=0.5) window.manual_stream = as_stream(start_stream) #window.getColor = get_color # WebFX will expose as Promise-returning JS function def post_start(context): print("Page loaded; ready for interaction.") sys.stdout.flush() window = context.window print(window.sync_one_arg("hello","there")) print(window.sync_two_args("hello","there")) # Asynchronous call via JS script = """ window.async_one_arg("test_value") .then(result => { console.log("Async result:", result); }) .catch(err => { console.error("Async error:", err); }); console.log("RRR"); """ context.browser.executeScript(script) return def launch(context): print("Interactive shell (optional)") import IPython; IPython.embed() webfx.quit() import traceback import sys def on_error(ex): # Print the full traceback to stderr traceback.print_exception(type(ex), ex, ex.__traceback__, file=sys.stderr) webfx = WebFx() webfx.start( pre=pre_start, post=post_start, on_error=on_error, launch=launch, home_page="resource:///color_test.html", file_path="local", # or wherever your HTML is classpath=["../dist/", "../lib/linux-x86_64/"], console=True )