Update java and ocaml bindings #2291

By the way: I just migrated my Java project from Capstone 4.0.2 to 5.0.9 and all integration tests fail due to an incorrect Java array size inside the Java binding. Codex hinted me that this is probably because the header in Capstone.h defines a size of 20:

#define MAX_IMPL_R_REGS 20

But inside the Java binding in Capstone.java it's still a size of 16:

public short[] regs_read = new short[16];

Am I getting something wrong? Did anybody test the Java binding since the recent versions? Is it worth opening an issue?

I created the binary based on the sources of 5.0.9 by:

CAPSTONE_ARCHS=x86 CAPSTONE_BUILD_CORE_ONLY=yes CAPSTONE_STATIC=yes CAPSTONE_SHARED=yes ./make.sh

To me, the availability of Java bindings are crucial. If they were dropped, I'd be forced to stay with an older version or to find a fresh new alternative.

You can try to run bindings/const_generator.py java to update the bindings files for v5.
If that works already, I would really appreciate it if you could open a PR.
Otherwise an issue please.

For the next branch (future v6) the process is way more work. Because so many modules were improved and the API changed, that it needs some proper work.

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.

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.

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.

@peace-maker In #2641 a user asked about the bindings as well. Coming back now I saw that my wording was bad here. I didn't want to discourage you at all to work on them! I am sorry if it sounded like this.

It would be very helpful if they are in a workable state!