We noticed that in certain circumstances a stream of data being sent to a server was being corrupted. According to the "onDataWritten" signal, we could see that the data which Stroke thought it was writing was valid, but by adding debug code to the JavaConnection class, we could see that what was actually being sent over the socket was wrong. For example, where "onDataWritten" would report something like some text for the server the actual data being written to the socket (as shown by toString() of the bytestream) would be something like: some text fo\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300 i.e. the length of data is correct, but the last part of the buffer is broken. We saw this on non-TLS connections, but never on TLS connections. The reason for this (verified after some debugging) is that the "ByteData.getData()" method was unsynchronized. In the failing cases, two threads are calling this method at once. The first one finds that "dataCopy_" is null, and so new's it and starts filling it with data. The second thread calls "getData()" before this completes, which means it sees "dataCopy_" as non-null, and uses that value (even though the first thread hasn't finished populating it yet). In the failing scenario, the two threads involved were (1) thread that was handling the "onDataWritten()" callback (which called "getData()" to get a String that it sent to a debug stream) and (2) the JavaConnection code (which wants to write the data to the socket). It seems likely that the reason this doesn't happen for TLS connections is that in that case, the JavaConnection object will be processing a ByteArray object that has been generated via the SSLEngine (rather than the one which "onDataWritten()" sees, and so the chance of two threads both calling "getData()" is reduced. (I have not followed the TLS code path thoroughly to verify this). So this change makes any method in ByteArray that touches "dataCopy_" be synchronized (as well as hashCode() as suggested by findbugs) Test-information: Having inserted some debug code, I could reproduce the "data corruption" problem reliably. After adding the "synchronized" directive to "getData()", I could no longer reproduce the corruption. Ran MLC with this patch and works with no problems Change-Id: I02008736a2a8bd44f3702c4526fd67369a3c136a Signed-off-by: Nick Hudson <nick.hudson@isode.com>