1. OMG Mailing List
  2. DDS PSM Java v1.1 Revision Task Force

All Issues

  • All Issues
  • Name: dds-psm-java-rtf
  • Issues Count: 17

Issues Summary

Key Issue Reported Fixed Disposition Status
DDSJAVA11-17 Correct inconsistency on the URLs for the machine readable documents DDS-Java 1.0 open
DDSJAVA11-6 Inconsistency in close() operations wrt. "throw java.io.IOException" declaration DDS-Java 1.0 open
DDSJAVA11-5 Operations with Collection as parameter should provide a "varargs" alternative DDS-Java 1.0 open
DDSJAVA11-12 StatusCondition should be immutable and have fluent API DDS-Java 1.0 open
DDSJAVA11-11 Error in Javadoc of DomainParticipantFactory.createParticipant(domain, qos, listener, statuses) DDS-Java 1.0 open
DDSJAVA11-8 In DomainParticipantFactoryQoS interface withPolicy() and withPolicies() have wrong parameters types DDS-Java 1.0 open
DDSJAVA11-7 The PolicyFactory class misses operations for Presentation and TopicData creation DDS-Java 1.0 open
DDSJAVA11-16 Missing "not" DDS-Java 1.0b1 open
DDSJAVA11-15 The resolution of the FTF Issue 15966 was partially applied DDS-Java 1.0 open
DDSJAVA11-10 The DataReaderQos interface misses a getReliability() operation DDS-Java 1.0 open
DDSJAVA11-9 Error in implementation of TypeSupport.newTypeSupport() DDS-Java 1.0 open
DDSJAVA11-14 In WaitSet all waitForCondition() operations should return the triggered conditions DDS-Java 1.0 open
DDSJAVA11-13 WaitSet should be aligned to the ISO C++ IDDS PSM DDS-Java 1.0 open
DDSJAVA11-2 ModifiableInstanceHandle should be removed DDS-Java 1.0 open
DDSJAVA11-1 The current Java PSM makes an implicit assumptions on member ordering DDS-Java 1.0b1 open
DDSJAVA11-4 Bucket accessors shall be removed DDS-Java 1.0 open
DDSJAVA11-3 RequestOffered.requestedOfferedContract() semantic should be removed DDS-Java 1.0 open

Issues Descriptions

Correct inconsistency on the URLs for the machine readable documents

  • Status: open  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    The machine-readable file URLs on the
    FTF report (ptc/15-09-21) and FTF 2 convenience document
    (ptc/15-09-13) disagree.

    The correct ones are the ones used in the FTF 2 document because these are consistent which the reference schema files that appear in the XML files also included as part of the specification.

    If nothing is done the URLs on the cover of the report (ptc/15-09-21) take precedence over the ones in the FTF2 specification, so it is imperative to re-issue the report to correct this.

  • Reported: DDS-Java 1.0 — Thu, 19 May 2016 00:35 GMT
  • Updated: Thu, 19 May 2016 00:37 GMT

Inconsistency in close() operations wrt. "throw java.io.IOException" declaration

  • Legacy Issue Number: 18424
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Operations with Collection as parameter should provide a "varargs" alternative

  • Legacy Issue Number: 18423
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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));

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

StatusCondition should be immutable and have fluent API

  • Legacy Issue Number: 18430
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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));

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error in Javadoc of DomainParticipantFactory.createParticipant(domain, qos, listener, statuses)

  • Legacy Issue Number: 18429
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In DomainParticipantFactoryQoS interface withPolicy() and withPolicies() have wrong parameters types

  • Legacy Issue Number: 18426
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The PolicyFactory class misses operations for Presentation and TopicData creation

  • Legacy Issue Number: 18425
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing "not"

  • Legacy Issue Number: 18652
  • Status: open  
  • Source: Software Pearls BVBA ( Laurence Vanhelsuwe)
  • Summary:

    "many of which do support Java EE"

    should be

    "many of which do not support Java EE"

  • Reported: DDS-Java 1.0b1 — Thu, 11 Apr 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The resolution of the FTF Issue 15966 was partially applied

  • Legacy Issue Number: 18582
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    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!

  • Reported: DDS-Java 1.0 — Wed, 27 Mar 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The DataReaderQos interface misses a getReliability() operation

  • Legacy Issue Number: 18428
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error in implementation of TypeSupport.newTypeSupport()

  • Legacy Issue Number: 18427
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In WaitSet all waitForCondition() operations should return the triggered conditions

  • Legacy Issue Number: 18432
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

WaitSet should be aligned to the ISO C++ IDDS PSM

  • Legacy Issue Number: 18431
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

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

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ModifiableInstanceHandle should be removed

  • Legacy Issue Number: 18420
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The current Java PSM makes an implicit assumptions on member ordering

  • Legacy Issue Number: 16096
  • Status: open  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    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.

  • Reported: DDS-Java 1.0b1 — Fri, 25 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bucket accessors shall be removed

  • Legacy Issue Number: 18422
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

RequestOffered.requestedOfferedContract() semantic should be removed

  • Legacy Issue Number: 18421
  • Status: open  
  • Source: ZettaScale Technology ( Mr. Julien Enoch)
  • Summary:

    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.

  • Reported: DDS-Java 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT