I decided to follow the principle that disposing local ref is kinda unsafe behavior and thus added a few procs that explicitly state this fact in their names: e.g. newJVMObjectConsumingLocalRef and fromJObjectConsumingLocalRef.
Old newJVMObject and fromJVMObject now never take ownership, they always create a new global ref.
I've moved fromJObject from autogenerated proc to a single generic proc for the sake of simplicity. newJVMObject is done via fromJObject to keep a single code path where global refs are created. As a slight benefit, finalizer is no longer generated for every wrapper type, but the single version is reused for all of them.
Version bumped to 0.3.0 to stress on some really minor backward incompatibility, which in 99% might not be even noticed.
Case when old code is affected:
User code relied on creating a lot of objects with fromJVMObject and newJVMObject so that they were deleted by Nim gc before returning to Java from native call. Such reliance was wrong anyway, but now since jnim JVM wrappers do not take ownership of the refs, the user might want to delete them manually (or use newJVMObjectConsumingLocalRef and fromJObjectConsumingLocalRef), especially if the number of such local references is not predictable until native returns to java.
So here goes.
newJVMObjectConsumingLocalRefandfromJObjectConsumingLocalRef.newJVMObjectandfromJVMObjectnow never take ownership, they always create a new global ref.fromJObjectfrom autogenerated proc to a single generic proc for the sake of simplicity.newJVMObjectis done viafromJObjectto keep a single code path where global refs are created. As a slight benefit, finalizer is no longer generated for every wrapper type, but the single version is reused for all of them.0.3.0to stress on some really minor backward incompatibility, which in 99% might not be even noticed.Case when old code is affected: User code relied on creating a lot of objects with
fromJVMObjectandnewJVMObjectso that they were deleted by Nim gc before returning to Java from native call. Such reliance was wrong anyway, but now since jnim JVM wrappers do not take ownership of the refs, the user might want to delete them manually (or usenewJVMObjectConsumingLocalRefandfromJObjectConsumingLocalRef), especially if the number of such local references is not predictable until native returns to java.