previous chapter table of contents next chapter


An entry for a factory must contain the factory, itself, hidden in a MarshalledObject and some string representation of the factory's class(es). It may also need other descriptive information about the factory. The UIDescriptor captures all this:

 package net.jini.lookup.entry; public class UIDescriptor extends AbstractEntry {     public String role;     public String toolkit;     public Set attributes;     public MarshalledObject factory;     public UIDescriptor();     public UIDescriptor(String role, String toolkit,                         Set attributes, MarshalledObject factory);     public final Object getUIFactory(ClassLoader parentLoader)            throws IOException, ClassNotFoundException; } 

There are several features in the UIDescriptor that we haven't mentioned yet, and the factory type appears to be missing (it is one of the attributes ).


A user interface will typically require a particular package to be present or it will not function. For example, a factory that creates a JFrame will require the javax.swing package. These requirements can provide a quick filter for whether or not to accept a factory ”if it is based on a package the client doesn't have, then it can just reject this factory.

This isn't a bulletproof means of selection. For example, the Java Media Framework is a fixed- size package designed to handle lots of different media types, so if your user interface is a QuickTime movie, you might specify the JMF package. However, the media types handled by the JMF package are not fixed, and they can depend on native code libraries. For example, the current Solaris version of the JMF package has a native code library to handle MPEG movies, which is not present in the Linux version. Having the package specified by the toolkit does not guarantee that the class files for this user interface will be present. It is primarily intended to narrow lookups based on the UIs offered .


There are many possible roles for a user interface. For example, a typical user may be using the service, in which case the UI plays the "main" role. Alternatively, a system administrator may be managing the service, and he or she might require a different user interface, in which case the UI then plays the "admin" role.

The role field in a UIDescriptor is intended to describe these possible variations in the use of a user interface. The value of this field is a string, and to reduce the possibility of spelling errors that are not discovered until runtime, the value should be one of several constant string values. These string constants are defined in a set of type interfaces known as role interfaces. There are currently three role interfaces:

  • The net.jini.lookup.ui.MainUI role is for the standard user interface used by ordinary clients of the service:
     package net.jini.lookup.ui; public interface MainUI {     String ROLE = "net.jini.lookup.ui.MainUI"; } 
  • The net.jini.lookup.ui.AdminUI role is for use by the service's administrator:
     package net.jini.lookup.ui; public interface AdminUI {     String ROLE = "net.jini.lookup.ui.AdminUI"; } 
  • The net.jini.lookup.ui.AboutUI role is for information about the service, which can be presented by a user interface object:
     package net.jini.lookup.ui; public interface AboutUI {     String ROLE = "net.jini.lookup.ui.AboutUI"; } 

A service will specify a role for each of the user interfaces it supplies . This role is given in a number of ways for different objects:

  • The role field in the UIDescriptor must be set to the String ROLE of one of these three role interfaces.
  • The user interface indicates that it acts a role by implementing the particular role specified.
  • The factory does not explicitly know about the role, but the factory contained in a UIDescriptor must produce a user interface implementing the role.

The service must ensure that the UIDescriptors it produces follows these rules. How it actually does so is not specified. There are several possibilities, including these:

  • When a factory is created, the role is passed in through a constructor. It can then use this role to cast the roleObject in the getXXX() method to the expected class (currently this is always a ServiceItem ).
  • There could be different factories for different roles, and the UIDescriptor should have the right factory for that role.

The factory could perform some sanity checking if desired; since all roleObjects are (presently) the service items, it could search through these items for the UIDescriptor , and then check that its role matches what the factory expects.

There has been much discussion about "flavors" of roles, such as an "expert" role or a "learner" role. This has been deferred because it is too complicated, at least for the first version of the specification.


The attributes section of a UIDescriptor can carry any other information about the user interface object that the service thinks might be useful to clients trying to decide which user interface to choose. Currently this includes the following:

  • A UIFactoryTypes object, which contains a set of Strings for the fully qualified class names of the factory that this entry contains. The current factory hierarchy is very shallow , so this may be just a singleton set, like this:
     Set attribs = new HashSet(); Set typeNames = new HashSet(); typeNames.add(JFrameFactory.TYPE_NAME); attribs.add(new UIFactoryTypes(typeNames)); 

    Note that a client is not usually interested in the actual type of the factory, but rather in the interface it implements. This is just like Jini services themselves , where we only need to know the methods that can be called and are not concerned with the implementation details.

  • An AccessibleUI object. Inclusion of this object indicates that the user interface implements javax.accessibility.Accessible and that the user interface would work well with assistive technologies.
  • A Locales object, which specifies the locales supported by the user interface.
  • A RequiredPackages object, which contains information about all of the packages that the user interface needs to run. This is not a guarantee that the user interface will actually run, nor a guarantee that it will be a usable interface, but it may help a client decide whether or not to use a particular user interface.

A Programmer[ap]s Guide to Jini Technology
A Programmer[ap]s Guide to Jini Technology
ISBN: 1893115801
Year: 2000
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net