Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
possible bug found #2
Thanks! It does look like that could cause a problem. I have never encountered an InterruptedException before, so I just printed the stack trace without thinking about it too much.
Links for reference:
Okay, so I've taken a look at it, and there's a few things that we can do here to fix it.
It seems that number 2 is the general way to do it using an InputStream. What probably makes the most sense here is to have a flag on the SerialPort which allows you to choose between these two methods, with option number 2 being the default.
I also noticed that at least on Windows, when the SerialPort is closed you will get an erroneous 0 back from the InputStream, instead of -1. See issue #3 for more information on that.
Updated BufferedSerialInputStream to optionally throw an IOException when an InterruptedException is thrown. Added a function on the SerialPort to set this functionality. Fixed the inputstream returning 0 when the serial port is closed(at least on Windows), will now return -1. Needs to be tested on Linux. POM should no longer try to sign by default, only when we release.