Latest version not working on Windows

[tresf]

JSSC 2.10.1 is not able to receive serial data on Windows 11.

	List Ports	Open Port	Send Data	Receive Data
Linux	✅	✅	✅	✅
macOS	✅	✅	✅	✅
Windows	✅	✅	✅	🚫

• I'm testing using a Mettler Toledo P90 scale.
  • In previous versions of JSSC, sending W\n would return the weight value on this scale. This still works on Linux, and macOS but Windows no longer returns a value.
  • As a baseline for sending data, I testested Z\n to zero the scale and that works to "ZERO" the scale for all platforms so I believe JSSC is sending data just fine but unable to receive data on Windows.

Workaround:

• Downgrade to JSSC 2.9.6

Possible causes:

• Handle some IllegalArgument cases in readBytes #175
• Some error handling in get serial port names #171

@hiddenalpha FYI

[hiddenalpha]

What are the exact symptoms? Any exceptions? Other errors logged? How does the read behave? Is it just blocking? Returning null? etc ...?

[tresf]

What are the exact symptoms? Any exceptions? Other errors logged? How does the read behave? Is it just blocking? Returning null? etc ...?

I've updated the issue description to be much more specific. No visible errors currently. In short, TX is OK, RX is broken. TX and RX work fine on Linux and macOS.

[tresf]

How does the read behave? Is it just blocking? Returning null? etc ...?

I'm using the listener to receive the read events and they're never firing (at least not with the app I'm testing). I'll put the app into debug to see if anything at all is firing because I do some sanity filtering before it hits the client.

[tresf]

Testing my app in debug, 2.10.1 is working OK. I'm scratching my head here...

[tresf]

@hiddenalpha found it... For some reason debug slowed it down just enough to not throw an error... This is what I see...

Exception in thread "EventThread COM5" java.lang.IllegalArgumentException: byteCount 0. Expected range: 1..2147483647
	at jssc.SerialNativeInterface.readBytes(Native Method)
	at jssc.SerialPort.readBytes(SerialPort.java:514)
	at jssc.SerialPort.readBytes(SerialPort.java:661)
	at qz.communication.SerialIO.processSerialEvent(SerialIO.java:85)
	at qz.utils.SerialUtilities.lambda$setupSerialPort$0(SerialUtilities.java:259)
	at jssc.SerialPort$EventThread.run(SerialPort.java:1217)

This means the regression was introduced in #175

[hiddenalpha]

Very good :) This message enlightens the situation.

The result surprises me. I did not expect any code trying to read zero bytes (I've no idea why one should do this). If reading zero bytes really should work, I can adapt it, so a read of zero bytes is not considered an error.

Yep, agree with 175 introducing it.

[tresf]

The listener fires and then my code filters for SerialPortEvent.isRXCHAR() and I simply read the bytes, so there must be cases on Windows when the events are triggered before the buffer has had time to fill. AFAIR, this has been a long standing issue with JSSC as my code around this particular serial scale has always require STX/ETX to concat messages on the listener. This may be an underlying bug with how polling is occurring on Windows but that's how it's worked historically and unless we fix the underlying polling bug, we'll have to accomodate 0-byte messages.

Testing my app in debug, 2.10.1 is working OK. I'm scratching my head here...

Comically, the debugger must be allowing enough time for the buffer to be filling up, circumventing the underlying issue.

[tresf]

@hiddenalpha I was going to write my own patch to this, but then realized that I'm not entirely sure how the behavior should be for zero bytes. Please feel free to push directly to this branch:

https://github.com/java-native/jssc/tree/zero-bytecount

[hiddenalpha]

@hiddenalpha I was going to write my own patch to this, but then realized that I'm not entirely sure how the behavior should be for zero bytes. Please feel free to push directly to this branch:

https://github.com/java-native/jssc/tree/zero-bytecount

Hmm. I'm getting a 404 there. Nevermind :) I opened pull #193 meanwhile.