Allow to add a port candidate to a RXTXCommDriver

[maggu2810]

See #23

Normally a NoSuchPortException is raised, if you try to get a port identifier for a not commonly used device name. This change allow us to add device candidates in the code by using the following lines:

final RXTXCommDriver rxtxCommDriver;
rxtxCommDriver = new RXTXCommDriver();
rxtxCommDriver.initialize();
if (rxtxCommDriver.addSpecifiedPort(device, CommPortIdentifier.PORT_SERIAL)) {
    CommPortIdentifier.addPortName(device, CommPortIdentifier.PORT_SERIAL, rxtxCommDriver);
}

Dit not know, if this is a "good" solution / workaround.

We could also change the internally hold list of names of common ports, ... But perhaps this list should not be changeable at runtime.

[maggu2810]

Hm, but this means, to remove added specified ports, we have to call "static public Enumeration getPortIdentifiers()" (so CommPortIndex is set to null and initialized with a RXTXCommDriver without any added port). Is this ok?

Could you get me some documents about the architecture?

[madhephaestus]

You might want to look at how i solved this for my Wrapper class NRSerialPort. It is an addition to the RXTX API that simplifies the interface to RXTX for the end user. Part of that is setting additional possible serial ports to the list of searchable ports, not right to the list of found ports.

https://github.com/NeuronRobotics/nrjavaserial/blob/master/nrjavaserial/src/main/java/gnu/io/NRSerialPort.java#L34

[maggu2810]

Changing the system property could be done in a single threaded application. But if your application is using a lot of "independent" threads this is a bad thing (IMHO). If at least one thread changes the property for the serial ports, all other threads are affected. So another thread could fail to open a serial port, that was defined in the property before.

Every thread could handle a different OSGi bundle that are independent and no bundle knows something from the other bundle. "Thread 1" reads a configuration and will open the port defined here, same for "Thread 2". The application is started with "gnu.io.rxtx.SerialPorts=portThread1:portThread2". Now a new thread "Thread 3" reads the configuration and wants to open portThread3. It changes the property at runtime. This could break "Thread 1" and "Thread 2" because that implementation use the normal way. In the linked issue (begin of this PR), I linked to a bug report where a commit that changed the property in one OSGi bundle breaks all other bundled, that worked before.

With this PR, someone could implement "Thread 3" (a new OSGi bundle) that could open a port without changing the property and without changing something that works already.

[maggu2810]

But my change is also not correct, if a call to getPortIdentifiers() will revert the addPortName(). Have to check that later.