Update openlcb.jar version to 0.6.5

Hi,

I'm sending you release 0.6.5 of the OpenLCB java libraries. It should go into lib/openlcb.jar.

thanks,
Balazs

Changelog:

r3927 | bracz | 2015-09-16 09:36:54 +0200 (Wed, 16 Sep 2015) | 3 lines

Packages version 0.6.5 of the java library for OpenLCB.

r3926 | bracz | 2015-09-08 23:40:51 +0200 (Tue, 08 Sep 2015) | 3 lines

Recompiles jar files after patches are applied.

r3925 | bracz | 2015-09-08 23:35:10 +0200 (Tue, 08 Sep 2015) | 3 lines

renames 0nmraCDI.xml to NMRAnetDatabaseTrainNode.xml to make unittest happy.

r3924 | bracz | 2015-09-08 23:23:14 +0200 (Tue, 08 Sep 2015) | 9 lines

patch by Bob Jacobsen: "Fixes timing issue in memory write replies."

This patch includes several changes:
- fixes a bug in the datagram transmit handler that could cause the transmit Memo pointer to be lost. Previously if the transmit callback would immediately send a new datagram, the new datagram would incorrectly not be entered as the next pending transmit Memo pointer.
- adds scaffolding for support in Memory Config protocol writes that may send back a (possibly delayed) return datagram instead of just a success/failure to the write request datagram. The write responses are not fully plumbed through to the caller though.
- extends unittests for datagram transmit Memo objects.

r3923 | bracz | 2015-09-08 22:30:17 +0200 (Tue, 08 Sep 2015) | 4 lines

Adds a regression test for the sign extension bugfix
https://sourceforge.net/p/openlcb/svn/3920/

r3922 | bracz | 2015-09-08 22:23:14 +0200 (Tue, 08 Sep 2015) | 5 lines

Adds test for MessageBuilder with aliases that have many high bits set.

Patch author: Bob Jacobsen.

r3921 | bracz | 2015-09-08 16:36:56 +0200 (Tue, 08 Sep 2015) | 25 lines

Fixed a bug in datagram acknowledgement handling that was leaking threads.

Previously if datagram traffic was present on the bus that JMRI is listening to, JMRI would incorrectly spawn a thread for each datagram sent between other nodes. The datagram acknowledgement handler was not checking whether the datagram OK message was actually targeted to JMRI and spawn a new handler thread no matter what.

Steps to reproduce:
1) start two JMRIs and connect to the same bus. These can run on different computers, or on the same computer with two CANUSB adapters, or connect to the same TCP hub.
2) Add a third node to the bus (e.g. a RailStars IO node would be fine)
3) from JMRI-A open the CDI condifuration tool for the IO node (go to openlcb->configure nodes -> select the io node, expand, expand supported protocols, click "CDI", wait for the configuration screen to open).
4) from JMRI-B do the same
5) get a thread list from JRMI-A (Help->System console... then click Print Stack Traces button)
6) observe a dozen or so threads with the following trace:

[4363] Thread-4310
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
org.openlcb.implementations.DatagramMeteringBuffer$Consumer.run(DatagramMeteringBuffer.java:164)
java.lang.Thread.run(Thread.java:745)

given enough time and enough many datagrams flying by, JMRI would crash the computer by starting tens of thousands of threads and exhausting the process ID space. The error received is fork: cannot allocate system memory.

r3920 | bracz | 2015-09-08 16:29:20 +0200 (Tue, 08 Sep 2015) | 4 lines

Fixes a sign-extension bug in addressed message handling.
Previously incoming addressed messages failed to look up the node ID in the alias map when bit 7 in the alias was 1 (e.g. alias 080), due to f.getElement(1) sign-extending to 0xffffff80 and corrupting the upper nibble of the alias to look up.