Re: [certi-dev] Java Binding

[Andrej Pancik]

On Sun, Feb 28, 2010 at 7:49 PM, Eric Noulard <address@hidden> wrote:
> 2010/2/28 Andrej Pancik <address@hidden>:
>> Hello,
>>
>>  A lot of identifiers have changed therefore it is necessary to modify
>> guts of Java libRTI.
>
> I know that and I'm concerned by the fact that those changes
> make you somehow redo what you have already done.
> However I find it essential in order to have a clean message specification
> and I hope that when the Java generator is ready changing
> content or name of a message may be done very fast.
> (for any binding using the generator including Java)



This will always bog when changing names of identifier since you have
to change them also in rti ambassador code which is not generated. But
it is not a problem I understand the importance of such effort and I
will do that as soon as proper generation of classes is done.



>> My estimation is that I need few hours to get new
>> compatible Java generator to work, however since I had only a brief
>> look I did not fully assess the problem.
>
> OK.
>
>> By the way I do not know any elegant way to determine what
>> corresponding data interface to use when serializing and deserializing
>> messages.
>
> The rules should be easy, let's take an example:
> message M_Reflect_Attribute_Values : merge Message {
>        required ObjectClassHandle  objectClass
>        required ObjectHandle       object
>        repeated AttributeHandle    attributes
>        repeated AttributeValue_t   values // FIXME check this one
>        optional EventRetractionHandle eventRetraction
> }
>
> A) plain non-repeated "scalar" field
>    like objectClass, object, eventRetraction
>
>   A.1) if they do have "representation" like
>   native AttributeHandle {
>    representation uint32
>    language CXX [#include "certi.hh"]
>    language CXX [#define ATTRIBUTE_HANDLE_UNDEFINED_VALUE 0]
>   }
>   you do know how to serialize them (with eventual cast during read/write)
>   I generate getter/setter pair for this kind of field e.g.:
>
>    ObjectClassHandle objectClass;
>
>   const ObjectClassHandle& getObjectClass() const {return objectClass;}
>  void setObjectClass(const ObjectClassHandle& newObjectClass)
> {objectClass=newObjectClass;}
>
>
>  A.2) the same is true for field which have "basic" types:
> uint8/16/32, double, float; string.
>
>  A.3) if they correspond to native type without representation
>  currently we cannot do anything beside hard-coding the solution in
> the generator.
>  In the current message specification there is "only" the Extent type
>  used in DDM messages and this is not handled properly even in C++ :-(
>  I'll tackle this as soon as we have a clean DDM test case.
>
> B) Optional field
>    When a field is optional I generate a boolean + the field itself e.g:
>
>    EventRetractionHandle eventRetraction;
>    bool hasEventRetraction;
>
>    Then you have the same rule as for the A) with conditionnal serialization
>    based on the value of hasXXX.
>    The value of the boolean itself is ALWAYS transmitted has an uint8.
>
>    NOTE: THERE IS NO "optional repeated" field keep reading.
>
> C)  Repeated field
>     A repeated field is a sequence of field of the same type thus
>     we serialize it as:
>        1) the sequence length serialized as an uint32
>        2) the field values serialized with rules A).
>
>    The sequence may be void but the sequence length is ALWAYS transmitted
>    this is why we don't need "optional repeated".
>
>    The getter/setter generated for the repeated fields are 6:
>
>    uint32_t getAttributesSize() const {return attributes.size();}
>    void setAttributesSize(uint32_t num) {attributes.resize(num);}
>    const std::vector<AttributeHandle>& getAttributes() const {return
> attributes;}
>    const AttributeHandle& getAttributes(uint32_t rank) const {return
> attributes[rank];}
>    AttributeHandle& getAttributes(uint32_t rank) {return attributes[rank];}
>    void setAttributes(const AttributeHandle& newAttributes, uint32_t
> rank) {attributes[rank]=newAttributes;}
>
>    using this libRTI may be implemented easily with some
>    hand-writtent helper functions used to convert from combined
> attribute/values
>    or parameter/value pairs to std::vector<AttributeHandle>
>    std::vector<AttributeValue_t> etc....



But that is the point. Helper functions should be called by generated
code. But to call them we need to know to which structure we want to
convert. This information is not supported by data right now.


>> From my point of view it is easier to decompose
>> AttributeHandleValuePairSet to r/w of arrays of handles and values
>> than to compose r/w of both arrays to AttributeHandleValuePairSet
>> while crawling through message definition file in linear fashion.
>> Since I need to provide AttributeHandleValuePairSet to libRTI I have
>> to convert the data explicitly somewhere anyway. It would be much
>> better if it was done on generator part.
>
> OK you got a point.
>
>> Just to be clear I am not opposed to "repeated" keyword. It has it's
>> important semantics. I just think that:
>>
>> "repeated HandleValuePair reflectedAttributes"
>>
>> is more appropriate to describe data strucuture than
>>
>> "repeated AttributeHandle    attributes
>> repeated AttributeValue_t   values "
>
> OK in order to support what you want we should find a way
> to describe how to serialize a native structure (like HandleValuePair)
> for which representation may not be mapped to "simple datatype".
>
> We may decide that such type should be something like:
>
> native HandleValuePair {
>        representation serialize
>        language CXX [#include "certi.hh"]
> }
>
> which would mean that there exist some "native"
> void serialize(MessageBuffer& msgBuf, HandleValuePair hvp);
> void deserialize(MessageBuffer& msgBuf, HandleValuePair& hvp);
>
> functions we can rely on.





If we use this approach I can include conversion (by calling
corresponding method) to complex type in de/serializefunction in
generated code
for example:

 repeated AttributeHandle attributes

can be automatically recognized by generator as

 AttributeHandleSet attributes;

and automatically transformed into proper de/serialization code.But
only if there are HandleValuePairs as different entities (to make 1-1
mapping).  I think that this is very convenient. Beta version of Java
libRTI (and also the beta generator) is made that way. I can make more
comments regarding this if needed.




> The other options would be to create a non native message type:
>
> message AttributeHandleValuePair {
>    AttributeHandle handle
>    AttributeValue   value
> }
>
> (note that this message doesn't need to inherit from Message
>  base class because it won't be sent on his own)
>
> then we can use
>
>     repeated AttributeHandleValuePair
>
> and generate the code accordingly.
>
> What would you prefer?



I like the first approach with native types.



> Either way in the libRTI you'll have to map the HLA enforced type
> (e.g. SuppliedAttributes) currently in the java implementation
> you use the same representation thus you can cast.



Not really. The point is that generator should know which type we want
at the end e.g. SuppliedAttributes and generate code that handles
aggregation from arrays to complex structures. Right now information
obtained in generation data is not sufficient to determine which
structure are we working with and combining arrays is up to programmer
of rti ambassador.




> In current CERTI C++ code we do copy because the representation
> in the message is not the same as the one in libRTI. It may be
> change in CERTI C++ but we would have to make a choice
> when going IEEE1516 for which we now have:
>  typedef std::set< AttributeHandle > AttributeHandleSet;
>
> and not a pure virtual class.
>
>> because "repeated AttributeHandle attributes" itself can correspond to
>> several SISO types and right now it is hard to determine in generator
>> which SISO type it should be mapped to.
>
> Why do you say that?
> Normally each attribute has its most precise type now:


Sorry if I did not write that explicitly. I did not mean simple types
but complex structures such as FederateHandleSet, SuppliedAttributes,
ReflectedAttributes etcetera,


> AttributeHandle
> ParameterHandle
> ObjectHandle
> ObjectClassHandle
> DimensionHandle
> etc...
>
> all these type have "representation uint32"
> (unless there is some typo remaining).
>
> so the generator should really know what to do with that.
> I did not begin the "modularisation" of the generator but I'll begin soon
> I'll try  add your request for supporting "native" non-simple type
> (at least at the generator syntax parsing level) during the work.


My response is included up there in the body of your email. I will try to write
more verbose explanation of my point of view on this issue tomorrow if
needed - please write if it is the case.

regards

Andrej Pancik