Tracking issue for Java binding catching up behaviors

[tisonkun]

Now that we have a behavior test framework for Java binding, it's possible to catch up features driven by the behavior tests compared with core's behavior tests.

For example:

• create_dir series test(binding/java): add create_dir test #3184
• copy series feat(binding/java): add copy test #3207
• rename series feat(binding/java): add rename support #3238
• list series feat(binding/java): add list & remove_all support #3333
• presign series fix(binding/java): fix return value of presign-related method #3433
• read_only series test(binding/java): add read_only test #3460
• list_only series
• ...

[tisonkun]

@G-XD you may extend the list above if you have time to sort out all the behavior our Java binding should support.

[G-XD]

@G-XD you may extend the list above if you have time to sort out all the behavior our Java binding should support.

Ok, I'll continue to refine the behavior tests of the java binding in my free time.

[tisonkun]

@G-XD since you're a committer now, you should be able to directly edit this issue :D

[G-XD]

Hi @tisonkun, @Xuanwo , I'm planning to support list operations on the java binding, should I patch the Metadata related functionality first?

[tisonkun]

should I patch the Metadata related

This can be reasonable. The last time I thought of list I found that we should wrap its return value (Entry) into a new NativeObject. Or we can make Metadata a POJO (as you did for OperatorInfo/Capability) and so does Entry.

[G-XD]

Currently only the ipfs service can trigger the list_only behaviors test, but ci is disabled for ipfs, so do I still need to add the list_only test to the java binding? cc @tisonkun @Xuanwo

[Xuanwo]

Currently only the ipfs service can trigger the list_only behaviors test, but ci is disabled for ipfs, so do I still need to add the list_only test to the java binding?

Let's ignore it until we have real use cases.

[Xuanwo]

Most work has been done, let's close!