

In such a case the corresponding source code distribution of RxTx needs to be obtained, which should contain complete instructions. On the other hand, some versions/builds/packages of RxTx come with incomplete instructions. Using the wrong one will result in a non-working installation. One for Java 1.2 and newer, one for Java 1.1. It should especially be noted that some versions of JavaComm come with two installation instructions. Many installation troubles simply come from not following the instructions precisely. If they say that a jar file or a shared library has to go into a particular directory, then this is meant seriously! If the instructions say that a particular file or device needs to have a specific ownership or access rights, this is also meant seriously.

It is highly recommended to follow the installation instructions word-for-word. The JavaComm and/or RxTx installation instruction (and follow it)īoth JavaComm and RxTX show some installation quirks. This is to be sure the test environment is set up correctly and you have understood the commands and responses from the device.ĭownload the API implementation you want to use for your particular operating system Use, for example, a terminal program to manually communicate with the device. Set up all hardware and a test environment Have the documentation of the device you want to communicate with (e.g. Learn the basics of serial communication and programming. Those who want to know what they are doing might find some useful information in this module. Those who want to blindly copy code are referred to the sample code that comes with the packages. It mainly focuses on demonstrating concepts, not ready-to-run code. This module discusses both JavaComm and RxTx. This way the application doesn't need to be changed, and can work against just one interface, the standardized JavaComm interface. So, by using JavaComm one can support all platforms which are either directly supported by Sun's reference implementation or by RxTx with JCL.
#Web serial port driver
If there is no JavaComm implementation for a particular platform available, but an RxTx implementation is, then RxTx could be used as a driver on that platform for JavaComm.

So, which of the libraries should one use in an application? If maximum portability (for some value of "maximum") is desired, then JavaComm is a good choice. Recently, RxTx has been adopted to provide the same interface as JavaComm, only that the package names don't match Sun's package names. RxTx supports more platforms than the existing JavaComm implementations. RxTx - if not used as a JavaComm driver - provides a richer interface, but one which is not standardized. Unfortunately, the reputation is further spread by people who don't know the basics of serial programming at all and make JavaComm responsible for their lack of understanding. Sun's negligence of JavaComm and JavaComm's particular programming model gained JavaComm the reputation of being unusable. When used as a JavaComm driver the bridging between the JavaComm API and RxTx is done by JCL (JavaComm for Linux). It can be used in conjunction with JavaComm (RxTx providing the hardware-specific drivers), or it can be used stand-alone. RxTx is available for a number of platforms, not only Linux. This situation, and the fact that Sun originally did not provide a JavaComm implementation for Linux (starting in 2006, they now do) led to the development of the free-software RxTx library.
#Web serial port windows
JavaComm hasn't seen much in the way of maintenance activities, only the bare minimum maintenance is performed by Sun, except that Sun has apparently responded to pressure from buyers of their own Sun Ray thin clients and has adapted JavaComm to this platform while dropping Windows support. Third party implementations for some of the omitted platforms are available. Particularly, at the end of 2005 Sun silently withdrew JavaComm support for Windows. Sun provides a reference implementation for a few, but not all Java platforms. Sun has defined a serial communication API, called JavaComm, but an implementation of the API is not part of the Java standard edition.

Unfortunately, Sun doesn't pay much attention to serial communication in Java. Serial interfacing requires a standardized API with platform-specific implementations, which is difficult for Java. Because of Java's platform-independence, serial interfacing is difficult.
