Change Log 0.8.1

Version 0.8.1 aligns the Digital Twin State with the Physical Asset Description: properties, events and actions now carry both a semantic type and a contentType (the format) in the State too.

Key updates:

• contentType in the DT State — DigitalTwinStateProperty and DigitalTwinStateEvent gain a contentType field (DigitalTwinStateAction already had it)
• New constructors that set both type and contentType
• Constructors with only the type are deprecated and will not be supported anymore from version 0.9.0
• equals/hashCode/toString of the State and Physical resources now include type and contentType; several NullPointerException in equals are fixed

No behaviour of the framework changes: the core never interprets type or contentType, it only stores and forwards them (state changes, state copies, observers), so existing code keeps compiling and running (with deprecation warnings).

Semantics#

A string that comes from the accelerometer of a specific device has type = "iot.demo.accelerometer" and contentType = "string".

The core does not know MIME types: both fields are plain strings, and it is up to the application (e.g., DigiWave) to give them a meaning.

API changes#

DigitalTwinStateProperty<T>#

New accessors: getContentType() and setContentType(String). If type or contentType are null they default to the name of the Class of the value (same default as PhysicalAssetProperty.contentType).

DigitalTwinStateEvent#

New accessors: getContentType() and setContentType(String).

DigitalTwinStateAction#

No API change (it already had key, type, contentType). Javadoc aligned: type is semantic, contentType is the format of the input.

Physical Asset Description#

Before / after#

// 0.8.0
dtState.registerEvent(new DigitalTwinStateEvent(event.getKey(), event.getType()));
dtState.createProperty(new DigitalTwinStateProperty<>(property.getKey(), property.getInitialValue()));

// 0.8.1: the semantic type and the format of the Physical Asset Description are copied in the State
dtState.registerEvent(new DigitalTwinStateEvent(event.getKey(), event.getType(), event.getContentType()));
dtState.createProperty(new DigitalTwinStateProperty<>(
        property.getKey(), property.getInitialValue(), property.getType(), property.getContentType()));

DigitalTwinStateProperty<String> accelerometer =
        new DigitalTwinStateProperty<>("accelerometer", "1.2,0.4,9.8", "iot.demo.accelerometer", "string");

accelerometer.getType();         // "iot.demo.accelerometer"
accelerometer.getContentType();  // "string"

Updating a property#

updatePropertyValue(...) changes only the value and keeps type and contentType. updateProperty(...) replaces the whole property: a property built with new DigitalTwinStateProperty<>(key, value) resets both fields to the Class name of the value. When only the value changes, use updatePropertyValue(...) (the examples of docs/getting_started.md have been updated).

Fixes#

• PhysicalAssetEvent.equals threw NullPointerException when contentType was null, which is exactly what the (key, type) constructor sets.
• DigitalTwinStateEvent.equals and PhysicalAssetAction.equals / DigitalTwinStateAction.equals now use Objects.equals (no NullPointerException with null fields).
• DigitalTwinStateEvent.toString printed PhysicalAssetEvent{...}.
• PhysicalAssetProperty.equals/hashCode ignored type and contentType; DigitalTwinStateProperty.hashCode ignored type. They are now consistent with equals.

Migration to 0.9.0#

1. Replace every new DigitalTwinStateProperty<>(key, value, type) with the constructor that also sets the contentType.
2. Replace every new DigitalTwinStateEvent(key, type) with new DigitalTwinStateEvent(key, type, contentType).
3. Replace new PhysicalAssetProperty<>(key, type, value) and new PhysicalAssetEvent(key, type) the same way.
4. When creating State resources from a Physical Asset Description, copy getType() and getContentType().

The compiler reports the remaining usages as deprecation warnings (-Xlint:deprecation).