Re: [certi-dev] CERTI Java Binding

[Eric Noulard]

2009/10/11 Andrej Pancik <address@hidden>:
> Dear CERTI developers,
>
>  as a school project I have been assigned implementation of CERTI Java 
> binding.

Thats good news for us ... including you :-)

> From my point of view it is possible to:
>  * recreate/program whole libRTI in Java that would communicate with
> RTI Ambassador via sockets
>  * link/wrap existing C++ implementation of libRTI with Java (it is
> probably possible to use some kind of automation in form of i.e.
> http://www.swig.org/ )
>
> Both solutions have pros and cons. I am in favour of the first one
> which seems to be clean and without JNI.

Most of us are in favour of the second solution.
See ML archive:
For example this thread:
http://lists.nongnu.org/archive/html/certi-devel/2008-07/msg00000.html

Some unfinished work has been already done in the past:
https://savannah.nongnu.org/task/index.php?6905

I don't know how much of it is re-usable.

> I would be very grateful for hearing your opinions, suggestions or
> just affirmation or STOP sign.

You should definitely go for the 100% java solution, i.e.
build a 100% java libRTI.

For following this path you'll have to:

1) Re-implement most of what you can find in
    certi/libRTI/*.cc

2) This will require the implementation of
   Messages classes which are the message exchange between
   Federate/libRTI and its RTIA.

I would suggest you to take the HLA services one-by-one
beginning with FederationManagement and do an incrementally
working implementation.

Concerning 2) you have 2 options.

 2a) do it manually
 2b) do it generatively

2b) is my favourite but may require more **initial** work.

I do have a preliminary message generator written in Python
see certi/scripts/GenerateMessages.py
(http://cvs.savannah.gnu.org/viewvc/certi/scripts/GenerateMessages.py?root=certi&view=markup)

which digest some message specifications
(inspired from Google Protocol buffer: http://code.google.com/p/protobuf/)
and  generate message classes in C++.

The code is designed to separate the generation backend
(C++, Java, Python) from other steps (parsing, building a kind of AST,
 checking AST,....)
You can write a Java generator backend AND the Message specification
you need to have.

Currently I did only write the NetworkMessage specification.

Depending on the time you have for your project you may chose
(an advice not more) to manually implement part of Federate<-->RTIA Message
or update the generator and write the specification for the needed message.

After that the work for writing the java libRTI version should be the same.

Keep us informed of your choices and your progress.

We'll try to help you as much as we can.

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