JavaKit: Java maintaining references to Swift values without Panama

[lhoward]

Edit: something I have found useful. Refactored to not use finalize(), and added links. Essentially:

import java.lang.ref.Cleaner;

class SwiftHeapObjectHolder implements AutoCloseable {
  private static final Cleaner cleaner = Cleaner.create();

  private final Cleaner.Cleanable _cleanable;
  public long _swiftHeapObject;

  public SwiftHeapObjectHolder(long heapObjectInt64Ptr) {
    final Runnable F = () -> SwiftHeapObjectHolder._releaseSwiftHeapObject(heapObjectInt64Ptr);
    SwiftHeapObjectHolder._retainSwiftHeapObject(heapObjectInt64Ptr);
    _cleanable = cleaner.register(this, F);
    _swiftHeapObject = heapObjectInt64Ptr;
  }

  @Override
  public void close() throws Exception {
    _swiftHeapObject = 0;
    _cleanable.clean();
  }

  static native void _retainSwiftHeapObject(long heapObjectInt64Ptr);
  static native void _releaseSwiftHeapObject(long heapObjectInt64Ptr);
}

https://github.com/PADL/FlutterSwift/blob/main/Sources/FlutterAndroid/com/padl/FlutterAndroid/SwiftHeapObjectHolder.java
https://github.com/PADL/FlutterSwift/blob/main/Sources/FlutterAndroid/SwiftHeapObjectHolderNativeMethods.swift

[ktoso]

No doubt you don't want to ship JARs.

? We'll absolutely be shipping some libraries or plugins as jars eventually.

[ktoso]

We should not be using finalizers if we can help it.

Please have a look at SwiftKit and the SwiftArena, this is the way to manage swift resources in Java, it's a more predictable modern way of doing so. There is an AutoArena which uses phantom references to release when references are dropped in a more efficient way.

[lhoward]

Ah, just thought that would make the build process even more of a pain the proverbial!

[ktoso]

Can we rephrase this ticket in terms of the problem to solve rather than propose the solution?

The "modern way" is SwiftArena and we should look into using it first if this is about any plain old "keep object alive while i have references to it in java".

[lhoward]

Sure. I wasn't aware of SwiftArena. But it looks like it requires Panorama, whereas Android I believe is still at JDK 17. Will confirm shortly.

[ktoso]

So funnily enough SwiftArena is not a JDK Arena type but its usage is very similar (but we never use it to "allocate"), the AutoSwiftArena just uses phantom references which have been around in the JDK for long.

I think we should pursue making that lib have some parts which are usable on older platforms as well, and that may include the AutoSwiftArena perhaps - then we don't have to invent another new way to solve the same issue 🤔 Maybe we'd do some swiftkit-core that's compatible with older platforms

[ktoso]

Thanks for the rename! :)

[lhoward]

Sounds good. I may not have the cycles to help on this but I'll have a think!

[lhoward]

Pleasure. Here I was thinking I had thought of something you hadn't.

[ktoso]

I'm sure you'll bump into a lot of things we've not thought about yet, this one I had a sneaky plan for though :)

[lhoward]

The biggest remaining issue for me is object/JNIEnv affinity, but there's an open issue for that 😉

[lhoward]

We should not be using finalizers if we can help it.

Please have a look at SwiftKit and the SwiftArena, this is the way to manage swift resources in Java, it's a more predictable modern way of doing so. There is an AutoArena which uses phantom references to release when references are dropped in a more efficient way.

Amusingly SwiftKit uses _typeByName() which I proposed nearly ten years ago. Must be getting old.

[ktoso]

We will actually stop using that as soon as I finish my “extract build plugin” PR, but yeah it’s still hidden api…