Update java and ocaml bindings

[Rot127]

The bindings for java and ocaml are massively out of date and not tested. It is certain that they don't work with the current next.

Would propose to remove them. Updating will be difficult because of #2089. And there were no bug reports in the recent months. Suggesting that they are pretty much not used.

If anyone is interested in updating them again, they can just restore them and work from there.
WDYT?

[keenk]

I haven't gotten to continue my work with Capstone in recent months, but I hope to eventually and it is based on the Java bindings.

[XVilka]

Just to keep the record, I am working on the OCaml bindings.

[Rot127]

@keenk How is it going with the Java bindings? Could you find time working on them?

[keenk]

I have not been working on it. Kind of surprised nobody else has either. What I had been doing was also focused on x86. The fact that nobody has stepped up to support that surprises me even more.

I don't want to make rash promises and then not come through. So if anyone else out there is thinking of working on the Java bindings, please go for it. Otherwise, maybe I can carve out some time to look at them in the not too distant future.

[peace-maker]

I've been poking at the Java bindings a bit. There are bindings for all architectures now and there's a Java implementation of the cstest tool too (translated from the Python version with help from Copilot 😆). I didn't translate the details checkers for all architectures yet.

I've noticed some fields in the test yaml files are handled by the C cstool but not by cstool_py like slice_offset_ir_set, so erroring on unhandled fields might be useful to keep the different cstool implementations in sync.

https://github.com/peace-maker/capstone/tree/java_bindings

Should we move the bindings library to a proper gradle library and include the capstone.so files for all platforms too? JNA supports embedding of dlls in the jar. Then it could be pushed to maven central or other registries.

[Rot127]

I was thinking writing a proper bindings generator is better. Independent of any language. We run way too often into these "some field is missing, some identifier is undefined, some check is not done" problems.

If we would generate most of the parsing logic, we could save most of the trouble. There are also tools for this which might help.

[Rot127]

As a general comment. It would be good if we could build a bindings generator directly. Something which parses the C headers with tree-sitter or something similar, and prints emits the source files in a given language. At least all the structs and enums should be generated. The actual binding functions can still be hand-written. But this would already ease the whole process a lot. Especially the update step.

See: #2468