The current signature of read() (and take) is:

public Sample.Iterator<TYPE> read();

This operation should return an Interable collection, to be aligned with the C++PSM:

public LoanedSamples<T> read();

An Iterable collection can be used in a foreach loop, and it can be managed by a try-with-resources block to return the loan automatically. An Iterator doesn't take advantage of these features.

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.

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 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 StatusCondition should be immutable and follow the same pattern than QoS policies:

public interface StatusCondition<ENTITY extends Entity<?, ?>>
extends Condition

This allow simpler code such as following:
waitset.attachCondition(
reader.getStatusCondition().withEnabledStatuses(DataAvailableStatus.class));

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

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.

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

"many of which do support Java EE"

should be

"many of which do not support Java EE"

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!

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

In TypeSupport class the newTypeSupport() operation is implemented as following:

public static <TYPE> TypeSupport<TYPE> newTypeSupport(
Class<TYPE> type,
ServiceEnvironment env)

The correct implementation should be:

public static <TYPE> TypeSupport<TYPE> newTypeSupport(
Class<TYPE> type,
ServiceEnvironment env)

Since type.getClass().getName() always return "java.lang.Class".

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

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

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.

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.

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.

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.