open-dis / opendis7-source-generator Goto Github PK
View Code? Open in Web Editor NEWProject to generate a type-safe Java implementation of the DIS Protocol version 7, IEEE 1278.1-2012 and SISO-REF-010 Enumerations specifications.
License: Other
Project to generate a type-safe Java implementation of the DIS Protocol version 7, IEEE 1278.1-2012 and SISO-REF-010 Enumerations specifications.
License: Other
The current implementation of unmarshaling PDUs performs some enumeration lookups of the extracted values. If the value isn't found, it returns a null
. This causes issues later in determining the unmarshalledSize()
of the PDU, resulting in a NullPointerException
(NPE).
One such scenario is seen in #14. ie: When some of the values are high end shorts (read as negative values), resulting in a failed enumeration lookup (no negative mappings in the enumeration classes), which returns a null for that instance. Later the parent object requests a .getMarshalledSize()
, which performs the same thing on all member objects, and as one is a null
the method bombs out.
But, as a lot of the Enumerations are filled with holes / incomplete, it's very easy to pull out a value that results in the null
.
In BeamStatus.java:getMarshalledSize()
:
marshalSize += beamState.getMarshalledSize(); // When `beamState` is not mapped from the enumeration possibilities, this is `null`, resulting in a NPE.
Sure, this particular example should be either on or off, but due to how it is unmarshalled, I've seen other values extracted from the byte. This could be related to the next issue (#7 ) though.
There are other PDUs though, such as the name of an emitter / radio / etc where it may not exist either.
If the mapping is insisted at PDU generation time, perhaps ensure that allgenerated Enumeration classes from the SISO standard (SISO-REF-010-v28 at time of viewing) contain an "unknown"/"invalid"/"other" mapping, and return that instead of null
? Some already do, but not all.
Hi!
I used the generated C++ bindings from open-dis-cpp
to get started on a project and they work great! But I need some changes. So I was just about to fork XMLPG and start making the changes I need, but then I found this project.
Thanks so much, and congrats on the useful libraries!
A "hyphen-ectomy" is planned, we are preparing to rename project from
This simplification with lead to more consistency in deliverables without reducing capabilities. This only applies to the "7" series of codebases using the XML program generator.
Look at approach used by IFF updates, determine best pattern for hashCode() methods in key Pdu methods.
This is related to issue #8.
target name="copy-generated-source-to-opendis7-java" copies files to dir="${opendis7-java}/src-generated" that are not generated by JavaGenerator.java and are not found on opendis7-source-generator project src-generated folder. (opendis7-source-generator projects' src-generated folder contains only files generated by JavaGenerator.java.)
-> Confusing moments for developers.
Solutions idea: a new ant target to opendis7-source-generator projects' build.xml for copying files from src-specialcase folder to folder that has the same name in opendis7-java project.
Following issue is observable when EntityTypes with domains not equal to PlatformDomain: The unmarhalled domain will always be PlatformDomain (see c'tor of EntityType), unmarshalled with the numerical value of the other enum class.
Here the test:
ByteBuffer buffer = ByteBuffer.allocate(4096);
try {
// marshal/ unmarshal Domain: correct
Domain d = Domain.inst(MunitionDomain.ANTI_ARMOR);
d.marshal(buffer);
buffer.rewind();
d.unmarshal(buffer);
System.out.println(d.getDescription());
buffer.clear();
// marshal/ unmarshal EntityType incorrect for entity types not equal PlatformDomain
EntityType ent = new EntityType();
ent.setEntityKind(EntityKind.MUNITION).setCountry(Country.GERMANY_DEU).
setDomain(Domain.inst(MunitionDomain.ANTI_ARMOR)).setCategory(1).
setSubCategory(1).setSpecific(3);
ent.marshal(buffer);
buffer.rewind();
EntityType et = new EntityType();
et.unmarshal(buffer);
System.out.println(et.toString());
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
which gives following output:
Anti-Armor
EntityType entityKind:EntityKind 2 MUNITION domain:Air country:Country 78 GERMANY_DEU category:1 subCategory:1 specific:3 extra:0
where the MunitionDomain.ANTI_AIR is now PlatformDomain.AIR as PlatformDomain.unmarshal was called despite having EntityKind.Munition.
There is a nasty issue for enumerations, where the enumeration value is initialzed by an integer with leading zeroes (this will be interpreted as an octal number by the compiler), e.g. for MunitionDescriptorFuse, where MULTIFUNCTION should have the decimal value 100, but the constructor in the source is MULTIFUNCTION(0100, "Multifunction"), which gives you a decimal value of 64. To my knowledge this is also valid for MunitionDescriptorWarhead, I have not searched for other cases, as one has to check the whole SISO-REF-010 enumerations.
Generated equalsImpl methods do unsafe checks for OBJECT_LIST type attributes. Method will throw IndexOutOfBoundsException when other object list is shorter that this object list. Equals method should not throw exceptions, list sizes should be compared before trying to access variables in the list.
If I understand correctly, I believe the ElectronicEmitter class is missing a 16-bit/2-byte padding field between numberOfBeams
and emitterSystem
that is missed during (un)marshalling (ref):
ie:
public int unmarshal(DataInputStream dis) throws Exception
{
int uPosition = 0;
try
{
systemDataLength = (byte)dis.readUnsignedByte();
uPosition += 1;
numberOfBeams = (byte)dis.readUnsignedByte();
uPosition += 1;
dis.readUnsignedShort(); // missing this 2-byte padding buffer.
uPosition += 2;
uPosition += emitterSystem.unmarshal(dis);
uPosition += location.unmarshal(dis);
for(int idx = 0; idx < numberOfBeams; idx++)
.
.
.
... and in here:
public void marshal(java.nio.ByteBuffer byteBuffer) throws Exception
{
byteBuffer.put( (byte)systemDataLength);
byteBuffer.put( (byte)beams.size());
byteBuffer.putShort((short)0); // needs to insert the (empty) padding field of the PDU.
emitterSystem.marshal(byteBuffer);
location.marshal(byteBuffer);
.
.
.
... and in the corresponding ByteBuffer
methods for marshalling and unmarshalling too.
I think there might be an issue with some of the fields being read out / unmarshaled using .readShort(), as this results in high end shorts (>32k) being negative. This could cause a few issues with lookups of enumerations - if they were populated that high.
So far in various simulation tools, I've encountered issues with ElectronicEmitterPdu
, EntityStatePdu
and the classes used within (EntityID
, etc) but I'm sure any part of the standard that references 2-bytes needs to be unsigned, so probably stored internally as an int
that's masked (0xFFFF
). Some are, but some aren't. Unsure on the lack of uniformity.
Raising this for further discussion on resolution or my use-case. :-)
Testing latest release exposed some new issues, reported to [email protected] mailing list.
Overrides currently in place:
Asked about warnings from empty XML children.
<subcategory value="31" description="Hz 21\24 Fast Bridge" includes a backslash character, which is problematic and needs to be forward slash
<enumrow value="2147483648" description="Rectangular Volume Record 4 value reduced by 1 as 2147483647 in order to remain a valid Java int
Hi again Don @brutzman,
I have noticed the TransmitterPdu
class extracts the RadioID
field (ref) once inside the header
field (see RadioCommsHeader
class), and again separately in the radioNumber
field. this causes an unnecessary shift of unmarshalling by 2 bytes. Removing it from the RadioCommsHeader
class fixes the problem, but so does commenting out the local field to the TransmitterPdu
class, and redirecting all calls to get/set of the RadioID
to the embedded RadioCommsHeader
instance's field. I'm not sure which way you want to go.
Let me know if you're the best POC, or if there's a preferred approach to raising these issues.
IFFPdu needs modifications so that Layer 3 information can be added to it. Layer 3 contains Mode 5 information.
Current IFFPdu only supports information for Layer 1 and 2. Current IFFLayer2Pdu extends IFFPdu which does not support to adding layer 3 information into IFFPdu.
Solution idea:
We would like to modify IFFPdu so that a layer information can be added directly to it and the layers do not need to extend IFFPdu.
Basically we would create corresponding data classes for layers 1, 2 and 3. (IffPduLayer1Data, IffPduLayer2Data, IffPduLayer3Data) These data classes would extend AbstractIffPduLayerData. Data classes can then be added to IffPdu via addLayer method. Then later when someone wants to create layer 4 and 5 they can simply create IffPduLayerData classes and add them to IffPdu.
Files that need modifications:
Is this solution okay to implement or do you have any suggestions for us how to improve it?
Much refactoring is nearly complete. open-dis7-source-generator products are feeding into the open-dis7-java build.
Still needed for release:
This work is being tested as part of a MOVES graduate course at NPS.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.