The longer technical explanation.

First a note that it might be useful to look at the full javadocs https://documentation.prosysopc.com/JSDK/javadoc/index.html, which is part of the web documentation added in 5.3.0 at https://documentation.prosysopc.com/JSDK/, the below uses direct links to methods in the javadoc.

Using PubSubConnectionDataType DataType as an example, in SDK versions below 5.3.0 the https://documentation.prosysopc.com/JSDK/javadoc/com/prosysopc/ua/stack/core/PubSubConnectionDataType.html#getAddress– used to return ExtensionObject. However, now it returns a https://documentation.prosysopc.com/JSDK/javadoc/com/prosysopc/ua/stack/core/NetworkAddressDataType.html. The PubSubConnectionDataType is an “AllowSubTypes Structure” type, the fields can be marked (in the information model) as allowing a subtype to be used. Normally subtypes aren’t allowed in Structure fields (or they anyway are encoded only as the defined type, not the subtype), because this would change the binary format thus breaking it. AllowSubTypes fields are encoded differently, using an ExtensionObject.

The OPC UA Specification also defines some “Extensible Parameter X” for some of the services parameters, for example here https://reference.opcfoundation.org/Core/Part4/v105/docs/5.11.3 has have “historyData Extensible Parameter HistoryData”. This concept pre-dates the AllowSubTypes fields concept. All the Extensible Parameter types used (and still use) the raw Structure type (i=22) as their DataType (in the information model). That has a special rule that it behaves similarly to modern an AllowSubTypes fields: the field is encoded as an ExtensionObject (https://reference.opcfoundation.org/Core/Part6/v105/docs/5.2.2.15 ), that retains the type information (thus decoder can decode it back). Non-Structure allowsubtypes fields are encoded as Variant (but skipped in this explanation).

The 5.3.0 changes that our Codegen tool now creates the exact type defined for a field. Thus for i=22 it creates ‘Structure’. For AllowSubTypes fields it is the fields defined type. However, this is only now possibly, since we added the ability for generated Structures to represent their non-generated subtypes. Otherwise for example if a (non-generated and then loaded) model would define a subtype of NetworkAddressDataType for PubSubConnectionDataType, it wouldn’t be “representable” as NetworkAddressDataType (since it is DynamicStructure since not generated) and the generated getter/setter would break. However, now all Structures are DynamicStructures thus NetworkAddressDataType can now represent the extra fields (you will need to use the generic processing APIs of Structure interface to access them) and the getter/setter works.

So for normal Structures it doesn’t do that much (except skipping the ExtensionObject.decode call), but for AllowSubTypes Structures the experience is improved more (since the getter/setter shows the actual type). Though, one change that didn’t make into the release was that I think we’ll probably try to add some annotation to generated setters that more clearly defines which fields are AllowSubType fields. For general processing it isn’t necessary (since that uses FieldSpecifications from the StructureSpecification i.e. Structure.specification()), but it would be a nice documentation addition.

P.S.
Who knows, maybe some-day in the OPC UA Specification the services-structures could be reworked as allowsubtypes structures, I think that should be a binary-compatible change at least for ones whose DataTypes aren’t visible in the address space. Or maybe we’ll add a way to somehow enhance the Codegen to be able to tell this information outside of the information model so that it would “magically know” that the ‘HistoryReadResult.getHistoryData()’ should always return a ‘HistoryData’ (but currently the information doesn’t exist in the core nodeset to my knowledge; it only exist for allowsubtypes structures and HistoryReadResult is not one).