feat(binding/java): add list & remove_all support

[G-XD]

Related: #3169

[tisonkun]

Let's wait a bit for the refactor PR #3332 and do a rebase. I assume that rebase this PR is simpler than rebase that one (for behavior tests). Sorry to make such conflicts.

[tisonkun]

Now you can do the rebase and I'll review this PR in about days - I'm a bit busy in today and tomorrow.

[G-XD]

Hi @tisonkun @Xuanwo , PTAL

[tisonkun]

I support the changes for:

• remove all
• list without args

Perhaps we can have another round to think of how to pass over args via JNI. But as long as we don't populate a large amount methods in this flavor, I can support to give it a try (as a baseline to improve).

BTW, how to convert list is another issue, you can take a look at this PR for another flavor. I don't have a strong preference for this point but we may align the pattern.

[Xuanwo]

BTW, how to convert list is another issue, you can take a look at this PR for another flavor. I don't have a strong preference for this point but we may align the pattern.

I'm not sure if builder pattern is a good idea in java like:

op.list_with()
    .limit(5)
    .startAfter(someElement)
    .join();

But anyway, I do agree with @tisonkun's comment that we can merge remove_all and list support first. We can try and discuss the api for list_with in following PRs.

[G-XD]

BTW, how to convert list is another issue, you can take a look at this PR for another flavor. I don't have a strong preference for this point but we may align the pattern.

Since the List is not returned directly in Operator, but rather CompletableFuture, I modified loadEnabledServices().

[tisonkun]

@G-XD One things to be verified:

• set_object_array_element is a native JNI call;
• List with put via JNI is crossing the language boundary.

Do you check which one is more efficient?

I prefer set_object_array_element and construct List with a preset array to avoid too many cross boundary invocations. But I don't do a performance test yet.

[G-XD]

Do you check which one is more efficient?

I didn't do a performance comparison test, but I think minimize marshalling of resources across the JNI layer is correct.

[Xuanwo]

What's the difference of List and Entry[]?

[tisonkun]

op.list_with()
    .limit(5)
    .startAfter(someElement)
    .join();

This is exactly what I expected to implement in Java API. Let's investigate it in a following PR.

Maybe

class Lister {
  private final Operator op;
  private int limit;
  public Lister limit(int limit) {
    this.limit = limit;
    return this;
  }

  public CompletableFuture<T> execute() {
   return executeNative(op, limit, <other args>); 
  }

  private static native executeNative( ... );
}

[tisonkun]

Generally looks good. Comments inline.

[Xuanwo]

Other LGTM from my side.

[tisonkun]

Merging...

Thanks for your excellent work!