Expand description
The Java backend of CodecTarget.
The same walk as the C column, spelled in Java. What that spelling settles, and why each of these is the backend’s answer rather than the walk’s:
- No pointers. A codec takes the sample as a reference, so
CodecTarget::memberisv.xandCodecTarget::wholeisv.CodecTarget::handoffhands the value either way, because there is no address to take and no array to decay. - No free functions.
runtime/cexportszdw_write_u32(w, x)andruntime/javahasw.writeU32(x); the walk asks forwrite_u32and each backend spells it. A codec for a type is astaticmethod rather than a function, for the same reason. - No forward declarations. A method may call one declared below
it, so
CodecTarget::routineanswersNoneto a prototype and the walk emits only bodies. That is the whole of what C’s declaration order costs, expressed once. - No unsigned types. A counter is
int; the runtime’swriteU32takes what fits and the widening is its business, not the generated code’s.
What is not different is the wire. runtime/java implements
DDS-XTypes 1.3 §7.4 from the clause, the same as runtime/c does,
and neither calls the other. Where the two columns disagree on an
octet, one of them has misread the specification — which is the only
reason to have a second column at all.
Structs§
- Java
- The Java backend.