[certi-dev] Java interface progress update number 2

[Andrej Pancik]

Hello again Certi developers,

 I think it's good time for another Java interface progress update.

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. To test overall architecture I have ported
one of the PyHLA sample federates (uav-send.py). It is able to
cooperate with slightly modified python federation uav-receive2.py
(also included in the release). The only modification is the removal
of "StructAttribute" as I did not know how exactly it should be
implemented in Java. However I have not really though about it for a
long time. Sorry for inconvenience.

If you want to write your own test federate there is also simple one
in the source tree (almost identical to
http://porticoproject.org/index.php?title=Getting_Started_With_Portico_Java
) which can be used as the base. But remember the very (Very) limited
number of messages and callbacks implemented.

Present LibRTI still lacks functionality of running rtia process
automatically as I found it somehow difficult to implement in Java in
non clumsy way. I will look into that later as it poses no problem
comparing to other tasks.
---------------------------------------------------

Installation instructions:
To test all of the functions implemented you need to have PyHLA
installed and working. Download
https://savannah.nongnu.org/task/download.php?file_id=19508 LibRTI.zip
file which contains zipped NetBeans project and compiled binaries in
dist directory. In this directory you can also find modified
uav-receive2.py and required .fed file.

Command chain required to run the test federation is
java -jar LibRTI.jar
rtig
rtia -p 2000
python uav-receive2.py
---------------------------------------------------

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? 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.

 * 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.

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

 * 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?

 * In TICK_REQUEST message minTickTime and maxTickTime values
(actually doubles) are transferred over socket in not very safe way:
"msgBuffer.write_bytes((char *)&minTickTime, sizeof(minTickTime));"
insetead of "msgBuffer.write_double(minTickTime);" I think it could
break the compatibility in some cases on systems with different
endianess.
---------------------------------------------------

regards

Andrej Pancik