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.
- 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.
- Replace the @return specification with the following:
Returns: true if service passes the filter; false otherwise.
- Add @see
- 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:
- SIChangeType.ADD indicates that the reported SI element
is new in the database.
- SIChangeType.REMOVE indicates that the reported SI
element is defunct and no longer cached by the database. The results of
subsequent method invocations on the removed SIElement are undefined.
- SIChangeType.MODIFY indicates that the data
encapsulated by the reported SI element has changed.
- 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.
- 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.
- 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.
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
place of the language concerning ServiceContext.select(Locator)
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
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.
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.
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
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.
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:
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:
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
- Add the following:
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:
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:
should note that the set of selected service components can be changed
by entities other than themselves, or as a side-effect of calls