Hi Robert and Ivan, I have been researching how to fix the 3rd step that Robert defined in his previous email (Fix BitBufferHelper). This code is in charge of handling bits and bytes for different network protocols (IPv4, IPv6, ICMP, ARP, etc.). As such, it needs to handle packet information at the bit level. And here is where the problem starts, because it has been documented that Java is not very efficient at this and it does not have proper support for unsigned numeric data:
http://www.darksleep.com/player/JavaAndUnsignedTypes.html https://stackoverflow.com/questions/4065776/how-do-i-declare-a-32bit-integer-in-java https://stackoverflow.com/questions/1032982/is-a-java-int-always-32-bits I guess this is the reason we have our own Uint8, Uint16, Uint32 and Uint64 data types. However, this classes do not support mathematical operations that are needed to filter information at the bit level. The methods at BitBufferHelper.java do need to perform this type of operations and that is the reason they use the native java data types (int, short, long). So my questions are the following: 1. Do we really need to replace int, short, long with Uint8, Uint16 and Uint32? The code is working as it is, and the change involves a lot of work and analysis. Do we really want to follow this path? 2. If the answer to the previous question is "yes", are there any other ODL features that have successfully done this change? I would like to see how this has been done, before I start proposing new code changes. Regards, David -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9088): https://lists.opendaylight.org/g/Discuss/message/9088 Mute This Topic: https://lists.opendaylight.org/mt/99883508/21656 Group Owner: discuss+ow...@lists.opendaylight.org Unsubscribe: https://lists.opendaylight.org/g/Discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
