When using the regular pRTI ambassador to publish an update on an object's attribute value there are no constraints on the 'completeness' of such object. That is, it is possible to register an update an object with some of the non-used or non-essential attributes with a null value. However, on the OORTI library there seems to be such a constraint: if the property of an object, on a second or lower level of hierarchy within the object tree is null, the updateAttributeValues() method rises a null-pointer related exception.
Requiring to set all possible attributes on a bean an all its related objects with non-null values pose a usability problem. For instance, if you need to create a PhysicalEntity with SpatialVariantStruct, you'd need to do (I estimate) hundreds of setters -at multiple levels- to create a 'complete' object tree for the latter.
If that's the expected behavior -that is, to fail when part of the entity object is incomplete-, it would be nice have more information when this happens. For instance, controlling this kind of null-pointer conditions and raising more informative exceptions informing which specific attribute is required/missing. This would save a lot of the time you would spend figuring out the issue by trial and error.
Note: a work around for this has been recursively initializing all the properties of the SpatialVariantStruct object tree.
To reproduce:
PhysicalEntity pe = new PhysicalEntity();
pe.setEntityType(new EntityTypeStruct());
pe.setMarking(new MarkingStruct());
pe.setUniqueId(UUID.randomUUID());
pe.setIncomingConnections(new IncomingConnectionStruct[]{});
var spatialStruct = new SpatialVariantStruct();
spatialStruct.setDeadReckoningAlgorithm(DeadReckoningAlgorithmEnum8.Static);
spatialStruct.setSpatialFPB(new SpatialFPStruct());
spatialStruct.getSpatialFPB().setWorldLocation(new WorldLocationStruct());
spatialStruct.getSpatialFPB().getWorldLocation().setX(worldLocationX);
spatialStruct.getSpatialFPB().getWorldLocation().setY(worldLocationY);
spatialStruct.getSpatialFPB().getWorldLocation().setZ(wordLocationZ);
pe.setSpatial(spatialStruct);
oortiamb.registerObjectInstance(pe);
oortiamb.updateAttributeValues(updatedPe, updateableAttributes, Integer.toString(0).getBytes()); //<-- where the null-pointer exception below is thrown
java.lang.NullPointerException
at nl.tno.oorti.accessor.LambdaAccessorFactory$LambdaAccessor.get (LambdaAccessorFactory.java:339)
at nl.tno.oorti.ooencoder.omtcodec.HLAfixedRecordCodec.getEncodedLength (HLAfixedRecordCodec.java:159)
at nl.tno.oorti.ooencoder.omtcodec.HLAvariantRecordCodec.getEncodedLength (HLAvariantRecordCodec.java:265)
at nl.tno.oorti.ooencoder.OOencoderImpl.encode (OOencoderImpl.java:54)
at nl.tno.oorti.impl.ObjectInstance.serialize (ObjectInstance.java:88)
at nl.tno.oorti.impl.ObjectInstance.serialize (ObjectInstance.java:66)
at nl.tno.oorti.impl.OORTIambassadorImpl.updateAttributeValues (OORTIambassadorImpl.java:813)
at nl.tno.nvgtestclient.NvgTestClientFederate.publishEntityAttributeUpdate (NvgTestClientFederate.java:137)
at nl.tno.nvgtestclient.NvgTestClientFederate.main (NvgTestClientFederate.java:220)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.mojo.exec.AbstractExecJavaBase.executeMainMethod (AbstractExecJavaBase.java:402)
at org.codehaus.mojo.exec.ExecJavaMojo.executeMainMethod (ExecJavaMojo.java:142)
at org.codehaus.mojo.exec.AbstractExecJavaBase.doExecClassLoader (AbstractExecJavaBase.java:377)
at org.codehaus.mojo.exec.AbstractExecJavaBase.lambda$execute$0 (AbstractExecJavaBase.java:287)
at java.lang.Thread.run (Thread.java:1583)
Unhandled exception in best-effort packet handler at 09:33:50:899 (2026.03.20)
Version: Pitch pRTI 5.5.12 build 11687 (Pitch Booster 2.5.2-rc1)
java.lang.InterruptedExceptionjava.lang.InterruptedException
at java.base/java.lang.Object.wait0(Native Method) at java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1727)
at java.base/java.lang.Object.wait(Object.java:366) at java.base/java.lang.ref.ReferenceQueue.await(ReferenceQueue.java:67)
at java.base/java.lang.Object.wait(Object.java:339) at java.base/java.lang.ref.ReferenceQueue.remove0(ReferenceQueue.java:158)
at se.pitch.prti1516e.hcs.c.i(prticore_b11687:340) at java.base/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:234)
at se.pitch.prti1516e.hcs.c.h(prticore_b11687:249)
at se.pitch.prti1516e.hcs.c.run(prticore_b11687:197)
at java.base/java.lang.Thread.run(Thread.java:1583)
at se.pitch.prti1516e.util.CleaningManager$a.run(prticore_b11687:122)
When using the regular pRTI ambassador to publish an update on an object's attribute value there are no constraints on the 'completeness' of such object. That is, it is possible to register an update an object with some of the non-used or non-essential attributes with a null value. However, on the OORTI library there seems to be such a constraint: if the property of an object, on a second or lower level of hierarchy within the object tree is null, the
updateAttributeValues()method rises a null-pointer related exception.Requiring to set all possible attributes on a bean an all its related objects with non-null values pose a usability problem. For instance, if you need to create a
PhysicalEntitywithSpatialVariantStruct, you'd need to do (I estimate) hundreds of setters -at multiple levels- to create a 'complete' object tree for the latter.If that's the expected behavior -that is, to fail when part of the entity object is incomplete-, it would be nice have more information when this happens. For instance, controlling this kind of null-pointer conditions and raising more informative exceptions informing which specific attribute is required/missing. This would save a lot of the time you would spend figuring out the issue by trial and error.
Note: a work around for this has been recursively initializing all the properties of the SpatialVariantStruct object tree.
To reproduce: