Deprecation of JMonitor due to Java 25 limitations: Seeking feedback on replacement API

[Thrameos]

Problem Statement

In the transition to the new J2NI backend, we are hitting a hard technical wall regarding Java monitor locks. In current versions of JPype, users can lock Java objects using Python's context manager syntax:

with JMonitor(obj):
    do_something()

Historically, this worked by calling JNI MonitorEnter and MonitorExit to apply single-sided lock/unlock commands across the language barrier.

This pattern is no longer viable. Starting in Java 25, Java has completely locked down these mechanics. Java now strictly enforces structured locking. The JVM requires that a lock be acquired and released within the exact same Java execution frame. Because Python’s with statement splits locking and unlocking into two separate actions (__enter__ and __exit__), we can no longer safely guarantee or execute this lifecycle from the native side.

As a result, we are planning to deprecate and eventually remove JMonitor.

---

Proposed Replacements (Seeking Input!)

To comply with modern JVM rules, any synchronization must happen within a Java-managed frame. This means we must pass a Python callable (a function or block of code) into a Java execution wrapper that handles the native synchronized(obj) { ... } block.

We are considering a few different API styles for this and want to hear what the community prefers.

Option A: The Decorator Pattern

Best for immediate, localized blocks of code. The decorator wraps the function and immediately executes it within the lock context.

@JSynchronizedExecute(obj)
def _():
    # Your synchronized code block here
    step_one()
    step_two()

Option B: Context Runner (Explicit Callback Function)

If you prefer a functional runner rather than a decorator, you can define a standard local function right above the runner. This keeps variable scopes clean and handles return values intuitively.

def my_atomic_operation():
    x = obj.getValue()
    obj.setValue(x + 1)
    return x

result = j_synchronized(obj, my_atomic_operation)

or 

# Inline alternative for quick, single-expression actions
result = j_synchronized(obj, lambda: obj.setValue(42))

We Want Your Feedback

1. How heavily does your codebase rely on JMonitor?
2. Which of the replacement syntaxes (Option A: Decorator, Option B: Context Runner) feels the most intuitive for your workflows?
3. Are there other API shapes you've seen in native interop tools that you prefer?

Please drop your thoughts below!