0

There is a lot of talk about Java serial port libraries like RXTX and JSSC, but what do they really provide? In both linux and windows you can simply open the serial port like a file for reading and writing, can't you? What is the advantage of using the libraries over just reading and writing from the device with file IO?

I understand that the libraries allow you to configure the ports, which would normally need to be done by commandline calls. But assuming the ports are already configured, is there any reason to use the libraries?

Dan Bliss
  • 1,694
  • 13
  • 10
  • 1
    They have the same benefits as using any other library. You don't have to do all the low-level, repetitive stuff yourself, it wraps all the details and minutia, and it's been tested by multiple users and had many of the bugs worked out. Most provide some protocol implementations as well. – Ken White Sep 06 '17 at 22:57
  • But with file IO it is just an InputStream and an OutputStream. That is not particularly low level, and it is compatible with socket IO, and file IO, which is commonplace in Java. I was wondering if I was going to encounter some pitfall that makes serial port streams unusable or difficult to manage. – Dan Bliss Sep 06 '17 at 23:02
  • But you can't assume that the port is open or configured correctly. With file I/O, you're using functionality from a library that implements the details of streams, right? You're not hand-coding all of the functionality of dealing with multiple operating systems, etc. each time you want to open and read from a file? Why aren't you writing all that low-level code yourself instead? Of course, it's because it's foolish to do so when Java already does it for you and handles all the details. Why would you expect serial operations to be any different? – Ken White Sep 06 '17 at 23:06
  • Well I can make the decision to treat serial port setup as part of OS configuration, correct? I mean maybe I am wrong about that, maybe that will break all the time or not persist across reboots or something. I was thinking that it was on the same level as OS configuration though, and I could configure that separately and then interact with it over simple streams. – Dan Bliss Sep 06 '17 at 23:18
  • I get the argument about not reinventing the wheel, but streams are standard practice, and cross platform. JSSC does not even seem to provide streams, so it seems like a downgrade in that regard. RXTX seems to be abandonware. If I can count on configuration of the serial ports to be done out of band, it seems like streams are the thing to do. – Dan Bliss Sep 06 '17 at 23:25
  • OK. It seems you've made up your mind that you don't want to use a library. Shrug... Don't use a library. (But *I can count on configuration* seems a lot like making an *assumption* that the configuration will be correct, and we all know what they say about *assuming*, right?) – Ken White Sep 06 '17 at 23:43
  • 1
    *"... just reading and writing from the device with file IO?"* -- I have no idea how much or what Java hides or abstracts. But read [this answer](https://stackoverflow.com/questions/25996171/linux-blocking-vs-non-blocking-serial-read/26006680#26006680) and the link in the first comment to get an idea of the differences between Linux and Windows APIs for serial port/terminal I/O. – sawdust Sep 07 '17 at 00:24

3 Answers3

1

Serial ports, historically, have been designed for slow communication lines such as modems. They have additional signals for "clear to send", "request to send", "data terminal ready", "hang up", "ring", etc. Some serial equipment still uses those. That stuff still exists in hardware, so a serial library should provide an API to access it.

Another thing are the interrupts. You might not want to poll the connection all the time to see if there is data available. Serial APIs usually provide a callback or an event handler for that.

Opening and closing port is best done in-application. Strictly speaking, it's not neccessary, but it's good practice not to expect a particular port being open at start or leave it locked on exit.

jurez
  • 4,436
  • 2
  • 12
  • 20
  • Will "request to send" and "clear to send" be used incorrectly if I dont use the library? Or is that just low level stuff that I will not have direct knowledge of if I don't use the library? As for the polling, I am planning to poll it just like I would poll a pipe or a socket. It seems like overkill to bring a library in if streams will handle it. – Dan Bliss Sep 06 '17 at 23:10
  • You can check the cable. For example, if there are only 2 pairs of wires, you know that no other signals are being used. Ultimately, it depends on the manufacturer who designed the device. If you can, check the documentation and do not assume it's correct if it's working for you just now. – jurez Sep 06 '17 at 23:15
  • Yeah I wish the documentation had that kind of information but I am SOL on that for these devices. It is an interface that is designed for human interaction as a terminal, and I am making a program to operate it automatically. It seems like overkill to use these libraries when I cat can use the connection just fine. (especially for JSSC which does not even provide a stream at all) – Dan Bliss Sep 06 '17 at 23:21
  • * I meant to say when the linux tool "cat" can use the connections just fine. – Dan Bliss Sep 06 '17 at 23:28
  • 1
    I've had my share of doubts using rxtx, too. Unless you're extremely tight on resources, the libraries should not be an overkill. However, they can be a pain because they require native libraries and might be buggy. If you are doing it on a closed/embedded system, it probably doesn't matter much as you can set everything up in a predictable and deterministic way outside java. In that case you'll likely be just fine using file I/O, especially on Linux. – jurez Sep 06 '17 at 23:32
  • *"Another thing are the interrupts."* -- The OS has already installed a device driver to handle those interrupts. The application or a library does not need to handle any interrupts or *"poll the connection"*; that is all performed by the OS. – sawdust Sep 07 '17 at 00:14
  • @sawdust: yes, the device drivers are installed by the OS, but without the library, you don't have the advantage of being notified when data arrives. You need some way of hooking your program into OS, and that's exactly what serial library is for. Remember the question is about java program. – jurez Sep 07 '17 at 06:35
1

In both linux and windows you can simply open the serial port like a file for reading and writing, can't you?

While this is possible to do, it's not really a recommended way to do it. To go to your second point:

But assuming the ports are already configured, is there any reason to use the libraries?

Assuming the ports are configured and configured properly, then it's perfectly possible to simply open up the serial port and read and write it like a normal file. This does come with another caveat though: that if you depend on the control signals at all, you won't be able to get that data from the port. Most serial devices that I have worked with don't do anything with the control lines at all, but that's not something that you can always be sure of.

The point behind using a library is so that you can get and set the exact settings that you need to in order to talk appropriately over the port.

As for JSSC/RXTX not having an InputStream/OutputStream for them, I didn't like that about those libraries either, so I wrote my own.

rm5248
  • 2,590
  • 3
  • 17
  • 16
0

Following is a quick list of why we may consider a library but largely I feel that if we are making a commercial product than ready made libraries may be good choice otherwise as a learner we can write our own.

  1. Uniformity across various operating systems. We have to write code for all supported OS which is a task in itself.
  2. The library authors may have more experience in that particular topic so quality might be better than us.
  3. Time to finish project (time to market) is another factor.
  4. Comprehensive test suite
  5. Beyond simple read/write can be extra features especially in case of GUI driven products like hot plugging and visual indications etc.
  6. Library might implement protocols or specifications means simple read/write may come wrapped in stream where the serial port specific things are hidden and a uniform layer is exposed to app.
  7. Support for wider range of hardware devices esp USB-UART Take a look at these 2 open source libraries 1st library and 2nd library
  8. Support for both Embedded and Desktop OS
Hercules dd
  • 215
  • 1
  • 5