About Java SerialPort

SerialPort is the world’s first (since 1996), and still foremost Java product for serial ports. SerialPort provides highly flexible control of serial ports from your Java application.SerialPort is a high-performance class that also provides low-level serial port control. If your device plugs into a serial port—on or off the Internet—it is almost certain that you can use SerialPort to communicate with it.

Applets

To implement applet support, you must create a ‘trusted’ applet. If you’re interested in creating trusted applets, ask about our Termlet Package which has the source code for our Termlet demo, and detailed instructions on how it was built. Note: you need Netscape Communicator 4.04 or later with the Java 1.1 patch to have full JNI support on Communicator. You use with Internet Explorer you need the MSVM with JNI support (the Java support option with IE5 provides this, there is also a VM upgrade for IE4).

Parallel Ports

Parallel ports are not nearly as universal as serial ports. If you need to communicate to a parallel port from Java we recommend using SerialPort to talk with a parallel port by way of a serial-to-parallel adaptor; this way, the same software can be used on virtually all platforms that SerialPort supports. The same will never be true of parallel ports since many platforms do not have parallel port hardware.

USB Ports

SerialPort currently supports USB-to-Serial converters. This allows you to communicate with standard RS-232 devices using the USB port(s) of your computer.

Comm API

Sun has said that the Comm API provides a Java extension API that allows applications that use the Comm API to be certified as 100% pure. Implementations of the Comm API are not 100% pure, meaning the Comm API implementations from Sun are not 100% pure. This is an unfortunate confusion since many people tend to think if it comes from Sun it is 100% pure. In summary, applications that use implementations of the Comm API may at some future time be capable of being labeled 100% pure. As far as we know, Sun has not yet provided the specs for testing to KeyLabs (the company that does 100% Java certification) meaning that applications using the Comm API are not 100% pure.

All SerialPort packages (except Lite versions) provide support for our javax.comm.SerialPort implementation of the Java Comm API. Our implementation of the Comm API was done entirely using the SerialPort API (a testament to the power and flexibility of SerialPort). Should you use the superior SerialPort API directly, or use javax.comm.SerialPort?

Use Case Examples

SerialPort is being used worldwide to provide solutions to more interesting problems than we could ever hope to keep track of, but below is a small sampling of use cases:

• Electronic payment
• GPS interface
• Digital camera interface
• Device interface control (local and remote)
• Meter reading and control
• Barcode scanner interface
• Modem control
• File transfer
• Robot communications and control
• Telex interface
• Remote shopping
• Sensor monitoring
• Remote camera control
• Electronic banking

Package Options

SerialPort is available with many package options to suit the needs of a great variety of developers.

Need to quickly and safely transfer files over any serial port or socket? Need to exchange data with legacy systems? Java ZModem, Java X/YModem and Java Kermit products are just waiting to cut weeks off your development schedule.

Implementation Requirements & Limitations

• Split flow control (handshake) is not supported for SerialPort versions previous to 3.2.
• Parallel ports are not currently supported (Parallel ports don’t even exist on many of the platforms that SerialPort runs on)
• Port enumeration is not supported for SerialPort versions previous to 4.0.
• Port enumeration is currently supported on Win7/Vista/XP/2008/2003/NT/98/95, Mac OS X & OS/2, and only on JNI compliant VM’s. This feature requires jspWin.dll version 3.7 or later on Win32 and shared library version 2.8 or later on Mac, and 3.2 or later on OS/2.
• When an array of buf[size] is defined, and when InputStream.read(buf) is used, Sun’s implementation will return immediately after reading the available bytes (regardless of the size). Our implementation will block until size bytes are available (this is the most logical behavior). If you want to prevent blocking use rdyCnt=InputStream.available() and pass the rdyCnt returned to the InputStream.read(buf, off, len method where len=rdyCnt.