Replace ThreadLocal stack with ScopedValue #336

Merged

jwharm merged 1 commit from scoped-value into main

2026-03-14 21:26:41 +01:00

jwharm commented

2026-03-14 21:26:29 +01:00

Owner

This is a small optimization in the InstanceCache. There is no functional impact.

When a new GObject subclass is constructed from Java, the Java object exists before the native instance. The native instance is then created by g_object_new, which calls back into the JVM for the instace_init_func. That causes an automatic type lookup in the Java-GI InstanceCache class. At that point we've lost track of the original Java instance, causing all sorts of trouble.
To solve this, I previously used a stack of "objects under construction" in a ThreadLocal field. Since the upgrade to JDK 25, we can instead use a ScopedValue. The ThreadLocal stack implementation has been removed because ScopedValues can be safely nested.

This is a small optimization in the InstanceCache. There is no functional impact. When a new GObject subclass is constructed from Java, the Java object exists before the native instance. The native instance is then created by `g_object_new`, which calls back into the JVM for the `instace_init_func`. That causes an automatic type lookup in the Java-GI InstanceCache class. At that point we've lost track of the original Java instance, causing all sorts of trouble. To solve this, I previously used a stack of "objects under construction" in a ThreadLocal field. Since the upgrade to JDK 25, we can instead use a ScopedValue. The ThreadLocal stack implementation has been removed because ScopedValues can be safely nested.

jwharm added 1 commit

2026-03-14 21:26:29 +01:00