The Artima Developer Community
This article is sponsored by the Java Community Process.

Leading-Edge Java
The Web Within an Arm's Reach
Near-Field Communication with JSR 257
by Frank Sommers
October 5, 2005

<<  Page 3 of 3


Communicating with RFID tags

While the Java Contactless Communication API can work on any mobile device, the API's main focus in the first release is RFID tags and barcode information. That focus is explained by the JSR 257 expert group's belief that RFID tags will find uses even beyond their current niche in manufacturing and inventory control. "While RFID is still relatively new, we believe it will find broad uses beyond what we see now," says Jaana Majakangas, a Nokia engineer, and specification lead for JSR 257. One area Majakangas forsees RFID use is in cell phones. Indeed, Nokia already offers a phone with RFID reading capability.

RFID is a collection of technologies centered around transmitting small amounts of data via low-energy radio frequencies. An RFID tag consists of a microchip capable of storing around 2 KB of data, sufficient to encode basic information about an object, such as its serial number or manufacturer name. Recent RFID tags often contain just a single 96-bit number, or product "license plate," that serves as a globally unique ID for the tagged object. Attached to that microchip is a tiny radio antenna that helps communicate with a nearby RFID reader device.

The least expensive RFID chips are read-only, with information imprinted in them during manufacture. More sophisticated RFID chips can be write-once/read-many, or even fully read-write capable. Chips that allow writing contain a header with a unique, non-erasable serial number, and some may even be programmed to restrict further write access.

Depending on the type of RFID tag, a reader device can access information in the tag from a distance of between a foot to several hundred feet. Difference in RFID read range is mostly due to whether a tag contains its own power source (active tag), or whether it derives its energy entirely from the electromagnetic field of the reader device (passive tag). Passive tags cost much less to manufacture, but require readers in close proximity.

To further reduce RFID tag manufacturing costs, instead of microchips, some RFID tags use plastics or conductive polymers to store data. And some tags don't even store data: Using special plastics, they reflect back to the reader only a well-defined portion of the radio waves targeted at them. The reader device captures those waves and computes the tag's identity based on what frequencies it received back.

While recent RFID applications each defined their own data formats, several industry consortia are working on standardizing the kinds of data recorded on RFID tags. Such standards will allow RFID-aware applications to work across organizational boundaries and even business domains. For instance, standard tag formats for personal medical records data might improve the sharing of electronic medical records, and even encourage the use of RFID chips implemented in the body for the purpose of facilitating instant access to potentially life-saving data. An example for such standardization is the Electronic Product Code initiative that aims to provide unique identifiers for any product in any industry that manages a supply chain[5].

In addition to standardized information on a tag, an equally important standardization effort aims to define the data-packaging format to exchange information between a reader and an RFID tag. Having such a standard format allows an RFID application to communicate with any device supporting that data exchange specification, regardless of the type of device. The Java Contactless Communication API follows the data exchange format currently being defined by the Near Field Communication (NFC) Forum[6]. The NFC specification encompasses a variety of near-field communication devices. Therefore an application using the Java Contactless Communication API would not have to care whether the discovered target is an RFID tag or some other NFC-adhering contactless target.

Reading From a Contactless Target

The concluding section of this article illustrates reading information from a contactless target. Such a target may be an RFID tag, or a cell phone capable of near-field communication. The only requirement the Contactless Communication API imposes on a device is that the device support the NFC communication standard.

Discovery of a nearby contactless target and reading data from that target is based on an event-driven programming model. That model will be thoroughly familiar to Jini developers. First, an application must register interest in newly discovered targets via a DiscoveryManager. When the DiscoveryManager discovers a new target, it invokes each of its TargetListener's targetDetected() method, passing in an array of TargetPropertys. Each element in that array represents a newly discovered target. Each TargetProperty, in turn, includes a URL representing a connection endpoint with the newly discovered device.

Since the URL to the device indicates the desired communication protocol, a handler for that protocol must be available to contact the newly discovered device. The Java Contactless Communication API does not care of the specific protocol used, and relegates protocol-level communication details to the J2ME general connection framework. Once a connection is established, the contents of that connection can be retrieved, including the service records stored on the device.

The following code snippet, taken from the Draft Specification version, illustrates reading an array of ServiceRecords from a device:

public class CCAPIExample implements TargetListener {
   private DiscoveryManager dm; 
   private ContactlessConnection conn = null;

   public CCAPIExample() {
      // Get DiscoveryManager instance and set TargetListener for RFID_TAG targets
       dm = DiscoveryManager.getInstance();

       try {
         dm.addTargetListener(this, TargetType.NFC_TAG);
       catch (IOException ce) {
          // Handle exception

   public void targetDetected(TargetProperties[] prop) {
     // If multiple targets discovered -> return
     if (prop.length > 1) {
        System.out.println("Multiple targets found");

     // Only one target found
     TargetProperties target = prop[0];

     try {

       // Open ContactlessConnetion to target
       conn = (ContactlessConnection);

       // Get the content of the target
       NFCContainer container =;
       ServiceRecord[] records = container.getRecords();
     catch (IOException ioe) {
       // Handle exception
     catch (ContactlessException ce) {
       // Handle exception

The resulting ServiceRecord class contains the name of the service record, and a byte array representing the record data. The meaning of that data is specific to an application. Recently emerging standards aim to specify records formats for a variety of applications. An application interested in contactless communication events would inspect the discovered service records and, if those records are of interest to the application, perform appropriate actions.

For example, such a record may represent the product identifier for a milk box, and may be attached to the box itself in an RFID tag. A consumer browsing a supermarket shelf could use an application on an RFID-capable cell phone to retrieve that product code and fetch nutritional or allergy-related information about the milk product. If a variety of products on that supermarket shelf sport similar RFID-embedded product codes, the mobile phone application can suggest the type of milk best matching the customer's nutritional profile or exercise regimen.

While the above code conveniently ignores exception handling, exceptions due to network failures are common occurrence in contactless communication, because devices may change position and move out of range at any moment. Thus, reading from a contactless communication may result in an IOException or ContactlessException that an application must deal with.


While this article thus far focused on the Contactless Communication API's ability to read RFID tags, the initial version of the API is designed to process barcode data as well. Barcodes are already ubiquitously imprinted on almost every consumer goods package, and even on some books and magazines. The Contactless Communication API enables camera phones to read and process such barcodes: You'd simply point your phone's camera to the barcode and launch a Contactless Communication-enabled Java application. Such an application could use a mobile version of the Java 2D API to process the graphics snapshot of the barcode, and hand that information over the Contactless API for further processing. From an application's point of view, reading the barcode via the API is similar to reading data from any contactless target.

The Contactless Communication API is currently in Public Draft Review stage in the JCP. Because the specification depends to a great extent on the NFC Forum's data format definitions, final form of this spec may have to wait until the NFC data formats firm up. However, that wait may be acceptable, since applications taking advantage of the convergence of multimedia and RFID-enabled cell phones and intelligent product identification are only now starting emerge. The Contactless Communication API will likely contribute to the proliferation of such applications, since it presents the variety of contactless targets via a simple, homogeneous interface to Java applications.

Talk back!

Have an opinion about the Java Contactless Communication API? Discuss this article in the Articles Forum topic, The Web Within an Arm's Reach.


[1] A podcast of Bill Joy's talk at the 2005 MIT Emerging Technologies Forum.

[2] Java Contactless Communication API, JSR 257

[3] For more information about RFID, see:

[4] The Jini Community's Web site

[5] Electronic Product Codes

[6] Near-Field Communication Forum

See also:

Infrared Java API. (No updates since 2000)

This Explorer for Nokia phones allows you to manipulate and send files via Bluetooth and infrared

Embedded Java Resouces

Java Bluetooth

Java BlueTooth API

About the author

Frank Sommers is a Senior Editor with Artima Developer. He also serves as chief editor of, the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Oversight Committee. Frank is also founder and president of Autospaces, a company dedicated to delivering rich-client Java enterprise solutions to small and medium-size businesses. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.

<<  Page 3 of 3

This article is sponsored by the Java Community Process.

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use