Skip to main content

Module java

Module java 

Source
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::member is v.x and CodecTarget::whole is v. CodecTarget::handoff hands the value either way, because there is no address to take and no array to decay.
  • No free functions. runtime/c exports zdw_write_u32(w, x) and runtime/java has w.writeU32(x); the walk asks for write_u32 and each backend spells it. A codec for a type is a static method rather than a function, for the same reason.
  • No forward declarations. A method may call one declared below it, so CodecTarget::routine answers None to 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’s writeU32 takes 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.