The following changes, previously described in MUG document #204, are proposed for the Java TV API 1.1.1 specification. :
In section “Creating Players and DataSources,” following the bullet “Attach the DataSource…”, add the following text:
It is possible to create multiple Players for the same scarce resource (such as a hardware video decoder).  However, doing so may affect the state of other Players which depend on that resource. :
  1. Add the following text to the method specification:
    The service passes the filter if, for one or more Locators specified in the filter constructor, locator.equals(Service.getLocator()) returns true.

  2. Replace the @return specification with the following:
    Returns: true if service passes the filter; false otherwise.

  3. Add @see :
  1. Replace the list that begins with the bullet “An SIChangeType of ADD” and ends with the bullet “An SIChangeType of MODIFY” with the following list:

  2. Replace the sentence beginning “In the event that the SIElement reported by this event…” with the following:
    In the event that the SIElement reported by this event is not the actual element that changed in the broadcast (i.e. it is instead a containing element or null), the value returned by getChangeType() will be SIChangeType.MODIFY. :
  1. Replace the sentence beginning with “If the connection hasn't been initialized…” with the following:
    If the connection hasn't been initialized, initCheck throws an Error.

  2. Add the following @throws statement:
    Throws: java.lang.Error if the connection has not been initialized. :
Add the following text:
Note that in some implementations of Java TV, there may be no two instances of Controller with compatible timebases.  In 
such cases, IncompatibleTimeBaseException will always be thrown.

overview.html :
Add the following text:
Java TV defines the following enumerated types:
Platforms including Java TV may define additional values for the above types through subclassing. Applications should not assume that methods using these types are constrained to the set of values defined as constants in Java TV; values unknown to the application author may be returned. Specification authors are advised not to define new values that semantically overlap with the values defined by Java TV or elsewhere.[]) :
In place of the language concerning[]) described in JSR 927 "maintenance draft review 3," add the following text to describe special rules for service-bound xlets:
Use of select(Locator[]) with Service-Bound Xlets
In some specifications incorporating Java TV, there is no mechanism to obtain the ServiceComponent that refers to xlets associated with the current service. Similarly, there may be no mechanism for obtaining a locator to a service component that represents a set of xlets that are part of a service. For this reason, the handling of service-bound xlets with this method is subject to some rather special rules.

If locators to xlets are listed then the specified xlets will be started or will continue running, according to the normal rules of starting and stopping xlets. Other running xlets in the service context will be stopped, as is consistent with the normal rules of running xlets. If no locators to xlets are passed in this method, then the results depend on whether the instance of ServiceContext is the xlet’s “primary” service context or not.

If the instance of ServiceContext represents the service context in which the calling xlet is running, then it is called the “primary service context.” An xlet may obtain its primary service context by passing its XletContext to ServiceContextFactory.getServiceContext(XletContext). The primary service context also appears in the list of service contexts returned by ServiceContextFactory.getServiceContexts().

For the primary service context only, when selection succeeds in a call where no locators to xlets passed as arguments, the terminal will select the same xlets as would be selected by calling select(Service) on the service of which the specified service components are members.  For example,  the components belong to the same service as is currently being presented, then there will be no change to the running xlets.

In some specifications incorporating Java TV, an xlet may obtain instances of ServiceContext that are not the xlet’s primary service context. For such ServiceContext instances, there is no special handling of the xlet service components. Thus, if no locators to xlets are passed in as argument, xlets running in that service context are stopped, and no new xlets are launched. :
Replace the sentence:
The returned ServiceContext is the one from which the Service carrying the Xlet was selected.

With the sentence:
The returned ServiceContext is the one from which the Service carrying the Xlet was selected, and is the Xlet's "primary" ServiceContext. :
Add as the second-to-last paragraph:
If the Service that is currently selected in this ServiceContext is re-selected, its auto-start components are ignored and no change is made to the content being presented. A NormalContentEvent is generated immediately.[]) :
Add the following:
If some of the specified components are already being presented, these components continue to be presented and will not be restarted.  Their selection is considered successful and is immediately reported by a MediaSelectSucceededEvent. :
Add the following:
If the specified component is already being presented, it will continue to be presented and will not be restarted.  A MediaSelectSucceededEvent is generated immediately. :
In the class description, replace the sentence:
Applications should note that the set of selected service components can be changed by entities other than themselves.

With the sentence:
Applications should note that the set of selected service components can be changed by entities other than themselves,  or as a side-effect of calls to[]).