Re: [certi-dev] Java interface progress update number 2

[Eric Noulard]

2010/1/18 Andrej Pancik <address@hidden>:
> Hello again Certi developers,
>
>  I think it's good time for another Java interface progress update.

Thank you for the update Andrej.

> What have been done so far:
> Source code in present state is DLC HLA 1.3 compliant as long as we
> talk about already implemented messages. There are only 15 messages
> finished and others are waiting to be implemented by generator which
> is still work in progress.

Did you begin to work on that "message generator" part ?
When you do do not hesitate to ask to help if needed, I'll try be
responsive on that part.

> Notes, questions and points of interests:
>
>  * How should I behave to nonstandard methods (such as Tick2)? Should
> I add them to interface or keep it clean and cast RTIambassador to
> CertiRTIambassador every time I want to use them?

I think the explicit cast should be the right option.
This will make the may-be non portable extension explicit which is good.
One can even try/catch the cast in order to see if it's available etc...

However if the Federate cast to CertiRTIambassador the "CertiRTIambassador"
must have been imported

import certi.rti.impl.CertiRTIAmbassador;

thus making the Federate code  not portable... (because Java does not
have a preprocessor)
Ideally I would rather go for a soution which makes it possible to
write portable Federate
which in turns may dynamically inspect if some RTI extension are available.

This is clearly not a primary goal so for now I suggest you stick to standard
and then we/you may examine how to support extension.

> Adding them to
> interface would not break the compatibility with other RTIs. This
> issue is also related to closeConnexion as it can nott be called in
> destructor on exit as there is no such thing in Java. I will try to
> solve the latter issue with hooking on virtual machine but I can not
> guarantee it will work.

You implements finalize() method for the concerned class
http://stackoverflow.com/questions/171952/is-there-a-destructor-for-java

but that's true that you cannot know WHEN it will effectively be called.
Concerning some JVM runtime hook you may look at:
http://java.sun.com/javase/6/docs/api/java/lang/Runtime.html#addShutdownHook%28java.lang.Thread%29


>  * On a related note DLC HLA 1.3 C++ and Java have differences such as
> different return values of same methods or different types of same
> values. For example in Java handles are treated as integers and in C++
> they are unsigned longs. Should I comply the interface and cast the
> types every time used differently or should I just modify the
> interface? This would break the compatibility with other RTIs
> therefore I am in favor of the first solution.

I do agree with Petr answer compatibility and standardness should be
the primary goal.

>  * RESIGN_FEDERATION_EXECUTION message's resign action in C++ code of
> the RTI ambassador is never written or read. Is it all right?

This is an unimplemented feature, should be considered as a bug
for now, may be you can open a bug in the tracker for that?

>  * Similarly in UPDATE_ATTRIBUTE_VALUES message there is always
> written boolean value TRUE ("req.setBoolean(true);") at the end of the
> message. I am just curious what it is for?

The boolean indicates if the message is timestamped or not.
(this is illnamed and we should rename those when using Message Generator
 for the Message as we did for NetworkMessage).

I'm pretty sure we do NOT always write TRUE.

Which file/line number makes you think this is always the case?


>  * In TICK_REQUEST message minTickTime and maxTickTime values
[...]

nice catch, thank you.
Petr already fixed this.


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