java: introduce proper types and minimise reliance on ByteBuffer/byte[]

[axic]

Part of #548.

[atoulme]

I really like this idea. Would remove all guessing. Feels like you have some coding issues.

Do you intend for implementors to create Address, Bytes32 Uint256 objects? If so, they'll need public constructors.

[axic]

@atoulme thanks! This is still work in progress, hence the draft mode, but I think this would be the safest way to handle things. Only issue is Message which is a mess due to the pointer thingie.

[axic]

ByteBuffer is set to big-endian by default, but we want to set it to native endian (helper to set: https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#order(java.nio.ByteOrder)).

We can use ByteOrder for that: https://docs.oracle.com/javase/6/docs/api/java/nio/ByteOrder.html#nativeOrder()

[axic]

Need to add Result class, and also pass Result/Message in HostContext.call.

[axic]

This currently contains the desired API from the Java perspective, yet to actually implement all of this. I'm leaning towards now that the C part would need to just receive an instance of Result/Message and manually read/write the fields and compose the C struct, as opposed to trying to construct the C struct from within Java.

[axic]

With #706 Java support was dropped -- closing this.