Allow reading and writing structured objects in Java analysis

[atomb]

Right now, arrays of scalars can be read and written from the Java heap as monolithic entities. Similarly, it would be possible in principle to specify or extract the value of an object as a SAWCore record, but that's not currently implemented.

[brianhuffman]

The old Java stuff is obsolete, but we should make sure that the new crucible/jvm stuff supports the same feature.

[brianhuffman]

For crucible/jvm, issue #422 is specifically about reading and writing arrays. We'll have to think about whether it makes sense to read and write objects with named fields.

[brianhuffman]

One of the tricky things about mapping between JVM object field names and Cryptol record fields is that JVM field names are not just identified by name; the class name and type are also used to identify a field of an object. The class name of a field might be the class of the object, or else it could be a superclass. It's not obvious how users would typically want those fields to be organized. Should they be one flat record? But that doesn't work if some field names shadow the names from a superclass. We could have a record field called super that contains the fields from the immediate superclass (and then that record could contain another super field containing a record of fields from its superclass, and so on). But while that would work in general, it's a bit complicated and arbitrary, and might not match the way people would want to write their cryptol specs.

Basically, I'm thinking that this is not something we want to implement. The saw-script commands, as they exist now, let you define your own object-specific wrapper functions for the JVMSetup monad that let you specify objects with lots of fields at once, and you can combine the fields in whatever Cryptol expression you want, using tuples, records, sequences, or whatever matches the style of Cryptol spec you have. A hard-coded points-to declaration for entire objects at once will be much less flexible, and probably not nearly as useful. So I'm going to close this ticket as "won't fix", if that's ok with everyone else.