145.

  

Restrictions on Entries

Entries are shipped around in marshalled form. Exported service objects are serialized, moved around, and reconstituted as objects at some remote client. Entries are similarly serialized and moved around. However, when it comes to comparing them, this is usually done on the lookup service, and they are not reconstituted on the lookup service. So when comparing an entry from a service and an entry from a client request, it is the serialized forms that are compared.

An entry cannot have one of the primitive types, such as int or char , as a field. If one of these fields is required, then it must be wrapped up in a class such as Integer or Character . This make it easier to perform "wildcarding" for matching (see Chapter 5 for details). Jini uses null in the fields of Entry objects from the client to act as a wildcard. This will work for any class, including wrapper classes such as Boolean . The primitive types, such as boolean , have no values that can be used as a wildcard pattern, since all possible values ( true and false ) could be valid request values.

Jini places some further restrictions on the fields of Entry objects. They must be public, non-static, non-transient, and non-final. In addition, an Entry class must have a no-args constructor.