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.
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 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.
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.
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
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, lenmethod where