Issues for DDS PSM Java v1.1 Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 16096: The current Java PSM makes an implicit assumptions on member ordering Jira Issue DDSJAVA11-1
Issue 18420: ModifiableInstanceHandle should be removed Jira Issue DDSJAVA11-2
Issue 18421: RequestOffered.requestedOfferedContract() semantic should be removed Jira Issue DDSJAVA11-3
Issue 18422: Bucket accessors shall be removed Jira Issue DDSJAVA11-4
Issue 18423: Operations with Collection as parameter should provide a "varargs" alternative Jira Issue DDSJAVA11-5
Issue 18424: Inconsistency in close() operations wrt. "throw java.io.IOException" declaration Jira Issue DDSJAVA11-6
Issue 18425: The PolicyFactory class misses operations for Presentation and TopicData creation Jira Issue DDSJAVA11-7
Issue 18426: In DomainParticipantFactoryQoS interface withPolicy() and withPolicies() have wrong parameters types Jira Issue DDSJAVA11-8
Issue 18427: Error in implementation of TypeSupport.newTypeSupport() Jira Issue DDSJAVA11-9
Issue 18428: The DataReaderQos interface misses a getReliability() operation Jira Issue DDSJAVA11-10
Issue 18429: Error in Javadoc of DomainParticipantFactory.createParticipant(domain, qos, listener, statuses) Jira Issue DDSJAVA11-11
Issue 18430: StatusCondition should be immutable and have fluent API Jira Issue DDSJAVA11-12
Issue 18431: WaitSet should be aligned to the ISO C++ IDDS PSM Jira Issue DDSJAVA11-13
Issue 18432: In WaitSet all waitForCondition() operations should return the triggered conditions Jira Issue DDSJAVA11-14
Issue 18582: The resolution of the FTF Issue 15966 was partially applied Jira Issue DDSJAVA11-15
Issue 18652: Missing "not" Jira Issue DDSJAVA11-16

Issue 16096: The current Java PSM makes an implicit assumptions on member ordering (dds-psm-java-rtf)

The current Java PSM makes an implicit assumptions on member ordering when defining  DDS Types in POJO that is not inherently guaranteed by the Java Language Specification. The possible resolution for this issue is to require @ID annotations when defining DDS Types using POJOs. In this case the ID would be used to uniquely defining the order to the attribute members.  

The ModifiableInstanceHandle was not removed along with all other modifiable types.  As such it should be removed for consistency, useability and performances.      Specificaly the following methods should be removed:   - ServiceEnvironment.newInstanceHandle()   - DataReader.lookupInstance(ModifiableInstanceHandle handle, TYPE keyHolder)   - DataWriter.lookupInstance(ModifiableInstanceHandle handle, TYPE keyHolder)      And the following method should be modified to return InstanceHandle:   - Sample.getInstanceHandle()   - Sample.getPublicationHandle()    Notice: the returning ModifialbeInstanceHandle forces defensive copying with obvious consequences in term of performances.

Instead of providing the requestedOfferedContract() method for RxO comparison, the inherited Compare implementation should follow the RxO rules.      For instance: Deadline(2) > Deadline(5)  This change simplify the API and avoids the creation of temporary object when trying to evaluate RxO. Notice that, in this case, the natural ordering is still available via the Duration type.

Bucket accessors were supposed to be removed for all types (with exception of Time) as part of the FTF.  Apparently some bucket accessors are still present (in some cases as the only possibility - e.g. Subscriber.getDataReaders()).      This is very unfortunate since it forces defensive copies with the obvious performance impacts.  Furthermore it makes the API inconsistent.

The use of Collection for providing a single "parameter" is rather cumbersome and could be greatly improved by providing a "varargs" alternative.      Here is an example that showcases the issue:    p = dp.createPublisher(           dp.getDefaultPublisherQos().withPolicy(              pf.Partition().withName(Arrays.asList("MyPartition"))                ));      In this case a withName(String... names) operation will simplify the code as shown below:    p = dp.createPublisher(           dp.getDefaultPublisherQos().withPolicy(              pf.Partition().withName("MyPartition")                ));        Moreover the use of Collection type could lead to compilation error as in the following case:      statusCondition.setEnabledStatuses(Arrays.toList(DataAvailableStatus.class));

The Entity interface inherits from java.io.Closeable and overrides the close() operation to NOT throw java.io.IOException. But some inherited entities such as DataReader and DataWriter might have to throw IOException on closure as their implementation might use sockets.    On the other hand the Sample.Iterator interface also inherits from java.io.Closeable but its close() operation declare to throw IOException. There should not be any IOException in this case since the Samples are already received by the DaraReader

The PolicyFactory class provides operation to create all Policies but Presentation and TopicData.    Also, the Representation() operation should be renamed as DataRepresentation() to ensure consistency with the other factory operations (each is named accordingly to the type it returns).

In DomainParticipantFactoryQoS interface the following operation are defined:          public DomainParticipantFactoryQos withPolicy(              QosPolicy.ForDataWriter policy);          public DomainParticipantFactoryQos withPolicies(              QosPolicy.ForDataWriter... policy);    In both operations the correct parameter type should be QosPolicy.ForDomainParticipantFactory.

In TypeSupport class the newTypeSupport() operation is implemented as following:          public static <TYPE> TypeSupport<TYPE> newTypeSupport(              Class<TYPE> type,              ServiceEnvironment env)      {          return newTypeSupport(type, type.getClass().getName(), env);      }      The correct implementation should be:          public static <TYPE> TypeSupport<TYPE> newTypeSupport(              Class<TYPE> type,              ServiceEnvironment env)      {          return newTypeSupport(type, type.getName(), env);      }    Since type.getClass().getName() always return "java.lang.Class".

The DataReaderQos specifies accessors for all QosPolicy.ForDataReader policies but Reliability.

The Javadoc description of the DomainParticipantFactory.createParticipant(domain, qos, listener, statuses) operation is following:      "This operation creates a new DomainParticipant object having default QoS and no listener..."      It should be replaced with following:    "This operation creates a new DomainParticipant object with the specified QoS and the specified listener..."

The StatusCondition should be immutable and follow the same pattern than QoS policies:      public interface StatusCondition<ENTITY extends Entity<?, ?>>  extends Condition {         /* statuses accessor */     public Set<Class<? extends Status>> getEnabledStatuses();         /* parent accessor */     public ENTITY getParent();         /* Copy this StatusCondition and override the value of the statuses */     public StatusCondition<ENTITY> withEnabledStatuses(Class<? extends Status>... statuses);      }        This allow simpler code such as following:     waitset.attachCondition(        reader.getStatusCondition().withEnabledStatuses(DataAvailableStatus.class));

The WaitSet class should be aligned to the ISO C++ IDDS PSM with regard to the dispatch() operation and associated functor.

In WaitSet class, all waitForCondition() operation should return a Collection of the triggered conditions. The "activeConditions" parameter should be removed.

The resolution for the ISSUE 15996 required to remove all the operations of the kind:      "public void setQos(String qosLibraryName, String qosProfileName);"      from all DDS entities since this operation pollutes the DDS API with a specific way of configuring QoS policies. The accepted resolution was to introduce the concept of a QoSProvider that could provide QoS settings by fetching them from a URI.      That said the type org.omg.dds.core.Entity still contains the operation:     public void setQos(String qosLibraryName, String qosProfileName);      This should be removed!

"many of which do support Java EE"      should be       "many of which do not support Java EE"