Impact of optional members on a .Net application

2 posts / 0 new
Last post
Last seen: 8 years 8 months ago
Joined: 09/26/2014
Posts: 5
Impact of optional members on a .Net application

Reading the documentation for Extensible Types, it says that optional members are not supported in the .NET API. What exactly is the resulting behaviour of this? For instance, what happens if a Java application publishes a sample where some optional members are not set and a .NET application is subscribed to that topic? Will it result in a crash? Will the .NET application get null values for the unset fields? Will the publisher/subscriber simply not match?

 Also, what is the behaviour of the rtiddsgen application? Does it ignore the @optional directive when generating for .NET, or does it give an error?

If I'm looking to reduce bandwitdh by only sending a subset of the members, is there an alternative to @optional that would be supported by the .NET API?


Edit: We did some experiments and we stumbled onto an issue with the output of rtiddsgen in Java. Let's say we have the following IDL:

struct SomeStruct{

    long x;

    long long y; //@Optional


Then in the generated java code, y is defined as a Long (capital letter so that it's an object that can be null)

In the hashcode method of the generated Java code, it does something like:

int result = 0;

result += (int)x;

if(y != null)

     result += (int)y;


That last line doesn't work though, you can't cast a Long to an int in java. You can cast from long to int, or from Long to long, but not straight Long to int.


Sandra Rodriguez's picture
Last seen: 2 weeks 2 days ago
Joined: 11/24/2015
Posts: 20

Hi Philipe,

Support for optional members in .NET was first introduced in Connext DDS 5.2.0.

You asked about the behavior when use an IDL with an optional member between a publisher in Java and a subscriber in C# in a previous version. With respect rtiddsgen, in .NET it ignores the @optional and generates the code as if this was not specified. Hence, as this functionality is not supported, the application will not work well and data can be corrupted. They can stablish communication, but the content of the data received in the DataReader of the C# subscriber may not be correct.

Regarding your last question, in 5.1.0 there was an issue related to code generation of IDLs containing primitive optional members in Java, such as long long (CODEGEN-646). This is the reason why the hashCode() method was not correct. This issue has been fixed in 5.2.0.

I suggest you to use 5.2.0 instead of 5.1.0, where optional members are supported in .NET and the issue CODEGEN-646 has been fixed.