Re: [certi-dev] Java Binding

[Eric Noulard]

2010/3/12 Andrej Pancik <address@hidden>:
> Hello,
>
>  I have finished the preliminary version of second Java generator. It
> successfully parsers current proto message file and generates java
> message classes. The code is still very ugly - I will use native types
> better later when refactoring.

OK.

>  To download the current code visit:
> https://savannah.nongnu.org/task/download.php?file_id=19918

You may commit the GenMsgJava.py as you want yourself in CVS,
since you are the one working on it now just go ahead.

If you are not confident with CVS I can do it myself but I'd rather
help you do it yourself because you'll soon need to use CVS in order
to setup the Java binding part.

>
>  Anyway, the code of RTI ambassador needs changes in almost all of the
> messages but these changes can not be done until full message
> specification is in place. Should I add the missing parts of message
> specification or should I wait for you. I strongly suggest to do the
> adjusting of ambassador only once (so we must be sure that generation
> data are proper) since distribution of changes to rti ambassador code
> can not be done automatically and it is pretty time consuming (more
> than 500 manual changes). If you need more information about this
> issue I will be glad to describe it in extend.

No I think I can imagine that part. I did it for the C++ libRTI (and RTIA)
so I'm already convinced it's a painful process.

> Note #1:
> What do you think about putting in of the combined type name. Something like:
>
> combine AttributeHandleValuePairSet suppliedAttributes{
>           repeated AttributeHandle       attributes
>           repeated AttributeValue_t      values
>        }

I don't like it because:
    a) HLA 1.3 spec use differents names for the same thing
           C++ --> AttributeHandleValuePairSet
           Java --> suppliedAttributes
           Python --> <to be specified>

    b) IEEE-1516 do not use the same type as HLA 1.3 which is even worse
          C++-HLA13 --> AttributeHandleValuePairSet
          C++-IEEE1516 --> AttributeHandleValueMap

Functionnally all those types containes the very same things:
two sequences of the same size, one for handle, one for the values.

So if we use your approach we would have to specify a possibly long list of
combine for each different cases. My current idea is:

We specify a unique combine inside the concerned message spec,
here is an example for AttributeHandleValuePairSet combine.

message M_Update_Attribute_Values : merge Message {
        required ObjectClassHandle     objectClass
            required ObjectHandle          object
         combine AttributeHandleValuePairSet  {
           repeated AttributeHandle       attributes
           repeated AttributeValue_t      values
        }
        combine EventRetractionHandle {
           optional EventRetraction eventRetraction
        }
}

Then this combine is referred to as a "native" message whose
representation is "combine". In the native type you may have
one or more (or none) language specific lines which could contains
"anything" you want to help the "language" generator backend to generate
appropriate code for the combine. Currently you have

native AttributeHandleValuePairSet {
    representation combine
    language CXX   [combine AttributeHandleValuePairSet]
    language Java  [import hla.rti.SuppliedAttributes]
}

But you may enhance the native like this:
native AttributeHandleValuePairSet {
    representation combine
    language CXX   [combine AttributeHandleValuePairSet]
    language Java  [import hla.rti.SuppliedAttributes]
    language Java  [public
setSuppliedAttributes(hla.rti.SuppliedAttributes sa) {...} ]
}

moreover we can later ONLY MODIFY THE COMBINE native to:

native AttributeHandleValuePairSet {
    representation combine
    language CXX   [combine AttributeHandleValuePairSet]
    language CXX1516 [combine WhateverFancyHandleValuePairSet]
    language Java  [import hla.rti.SuppliedAttributes]
    language Java  [public
setSuppliedAttributes(hla.rti.SuppliedAttributes sa) {...} ]
    language Java1516  [import hla.rti.SuppliedAttributes1516]
    language Python [combineto AHVPS]
}

The idea is the message spec itself contains "functional" aspect whereas
the 'native' contains specific information for the language generator backend.
This my point of view on the best way to separate "pure" specification from
specific generator things but anyone listening here may step in and give
his/her opinion on that too.

> Note #2:
> My generator needs straightforward modification of of receive
> interaction and send interaction classes to something like this
>
> message M_Receive_Interaction : merge Message {
>        required InteractionClassHandle interactionClass
>    combine ParameterHandleValuePairSet
>    {
>    repeated ParameterHandle        parameters
>           repeated ParameterValue_t       values
>     }
>        required RegionHandle           region
>        combine EventRetractionHandle {
>           optional EventRetraction eventRetraction
>        }
> }

Go ahead you can do this kind of modification where ever you need them.
Then commit the CERTI_Message.msg file, I'll check for C++ compatibilty
for the file but It should be just fine to add any combine to the current file
without breaking C++ code.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org