river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter_firmst...@apache.org
Subject svn commit: r1444525 [2/2] - in /river/jtsk/skunk/qa_refactor/trunk: ./ dep-libs/rc-libs/ netbeans/onebigjar/nbproject/ qa/ qa/harness/policy/ qa/jtreg/net/jini/loader/ClassLoading/verifyBeforeLoading/ qa/jtreg/net/jini/loader/pref/PreferredClassProvid...
Date Sun, 10 Feb 2013 10:40:03 GMT
Modified: river/jtsk/skunk/qa_refactor/trunk/src-doc/static/specs/html/js-spec.html
URL: http://svn.apache.org/viewvc/river/jtsk/skunk/qa_refactor/trunk/src-doc/static/specs/html/js-spec.html?rev=1444525&r1=1444524&r2=1444525&view=diff
==============================================================================
--- river/jtsk/skunk/qa_refactor/trunk/src-doc/static/specs/html/js-spec.html (original)
+++ river/jtsk/skunk/qa_refactor/trunk/src-doc/static/specs/html/js-spec.html Sun Feb 10 10:40:02 2013
@@ -40,218 +40,218 @@
 <hr align="left">
 <table width="90%">
 <tr>
-<td align="right" font size="4"><b>Version 2.2</b></td>
+<td align="right" font size="4"><b>Version 2.3</b></td>
 </tr>
 </table>
-<a name="skip"></a>
+<a id="skip"></a>
 <blockquote>
 <h2 align="left">
-  <a name="31412"> </a>JS - JavaSpaces<font size="-1"><sup>TM</sup></font> Service Specification</h2>
+  <a id="31412"> </a>JS - JavaSpaces<font size="-1"><sup>TM</sup></font> Service Specification</h2>
 <h3 class="Heading2">
-  <a name="31414"> </a>JS.1	 Introduction	 
+  <a id="31414"> </a>JS.1	 Introduction	 
 </h3>
 <p class="Body">
-   Distributed systems are hard to build. They require careful thinking about problems that do not occur in local computation. The primary problems are those of partial failure, greatly increased latency, and language compatibility. The Java(TM) programming language has a remote method invocation system called RMI that lets you approach general distributed computation in the Java<TM) programming language using techniques natural to the Java programming language and application environment. This is layered on the Java platform's object serialization mechanism to marshal parameters of remote methods into a form that can be shipped across the wire and unmarshalled in a remote server's Java virtual machine<a href="#31491"><sup>1</sup></a> (<span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">JVM</span>).
+   Distributed systems are hard to build. They require careful thinking about problems that do not occur in local computation. The primary problems are those of partial failure, greatly increased latency, and language compatibility. The Java(TM) programming language has a remote method invocation system called RMI that lets you approach general distributed computation in the Java(TM) programming language using techniques natural to the Java programming language and application environment. This is layered on the Java platform's object serialization mechanism to marshal parameters of remote methods into a form that can be shipped across the wire and unmarshalled in a remote server's Java virtual machine<a href="#31491"><sup>1</sup></a> (<span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">JVM</span>).
 </p>
 <p class="Body">
-  <a name="1778"> </a>This specification describes the architecture of JavaSpaces technology, which is designed to help you solve two related problems: distributed persistence and the design of distributed algorithms. JavaSpaces services use <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> and the serialization feature of the Java programming language to accomplish these goals.
+  <a id="1778"> </a>This specification describes the architecture of JavaSpaces technology, which is designed to help you solve two related problems: distributed persistence and the design of distributed algorithms. JavaSpaces services use <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> and the serialization feature of the Java programming language to accomplish these goals.
 </p>
 <h4 class="Heading3">
-  <a name="27387"> </a>JS.1.1	 The JavaSpaces Application Model and Terms
+  <a id="27387"> </a>JS.1.1	 The JavaSpaces Application Model and Terms
 </h4>
 <p class="Body">
-  <a name="27409"> </a>A JavaSpaces service holds <em class="Emphasis">entries</em>. An entry is a typed group of objects, expressed in a class for the Java platform that implements the interface <code>net.jini.core.entry.Entry</code>. Entries are described in detail in the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>. 
+  <a id="27409"> </a>A JavaSpaces service holds <em class="Emphasis">entries</em>. An entry is a typed group of objects, expressed in a class for the Java platform that implements the interface <code>net.jini.core.entry.Entry</code>. Entries are described in detail in the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>. 
 </p>
 <p class="Body">
-  <a name="27420"> </a>An entry can be <em class="Emphasis">written</em> into a JavaSpaces service, which creates a copy of that entry in the space<a href="#27423"><sup>2</sup></a> that can be used in future lookup operations.
+  <a id="27420"> </a>An entry can be <em class="Emphasis">written</em> into a JavaSpaces service, which creates a copy of that entry in the space<a href="#27423"><sup>2</sup></a> that can be used in future lookup operations.
 </p>
 <p class="Body">
-  <a name="27450"> </a>You can look up entries in a JavaSpaces service using <em class="Emphasis">templates,</em> which are entry objects that have some or all of its fields set to specified <em class="Emphasis">values</em> that must be matched exactly. Remaining fields are left as <em class="Emphasis">wildcards</em>--these fields are not used in the lookup.
+  <a id="27450"> </a>You can look up entries in a JavaSpaces service using <em class="Emphasis">templates,</em> which are entry objects that have some or all of its fields set to specified <em class="Emphasis">values</em> that must be matched exactly. Remaining fields are left as <em class="Emphasis">wildcards</em>--these fields are not used in the lookup.
 </p>
 <p class="Body">
-  <a name="27463"> </a>There are two kinds of lookup operations: <em class="Emphasis">read</em> and <em class="Emphasis">take</em>. A <em class="Emphasis">read</em> request to a space returns either an entry that matches the template on which the read is done, or an indication that no match was found. A <em class="Emphasis">take</em> request operates like a read, but if a match is found, the matching entry is removed from the space.
+  <a id="27463"> </a>There are two kinds of lookup operations: <em class="Emphasis">read</em> and <em class="Emphasis">take</em>. A <em class="Emphasis">read</em> request to a space returns either an entry that matches the template on which the read is done, or an indication that no match was found. A <em class="Emphasis">take</em> request operates like a read, but if a match is found, the matching entry is removed from the space.
 </p>
 <p class="Body">
-  <a name="27464"> </a>You can request a JavaSpaces service to <em class="Emphasis">notify</em> you when an entry that matches a specified template is written. This is done using the distributed event model contained in the package <code>net.jini.core.event</code> and described in the <a href="event-spec.html"><em class="Emphasis">Jini Distributed Events Specification</em></a>.
+  <a id="27464"> </a>You can request a JavaSpaces service to <em class="Emphasis">notify</em> you when an entry that matches a specified template is written. This is done using the distributed event model contained in the package <code>net.jini.core.event</code> and described in the <a href="event-spec.html"><em class="Emphasis">Jini Distributed Events Specification</em></a>.
 </p>
 <p class="Body">
-  <a name="2902"> </a>All operations that modify a JavaSpaces service are performed in a transactionally secure manner with respect to that space. That is, if a write operation returns successfully, that entry was written into the space (although an intervening take may remove it from the space before a subsequent lookup of yours). And if a take operation returns an entry, that entry has been removed from the space, and no future operation will read or take the same entry. In other words, each entry in the space can be taken at most once. Note, however, that two or more entries in a space may have exactly the same value.
+  <a id="2902"> </a>All operations that modify a JavaSpaces service are performed in a transactionally secure manner with respect to that space. That is, if a write operation returns successfully, that entry was written into the space (although an intervening take may remove it from the space before a subsequent lookup of yours). And if a take operation returns an entry, that entry has been removed from the space, and no future operation will read or take the same entry. In other words, each entry in the space can be taken at most once. Note, however, that two or more entries in a space may have exactly the same value.
 </p>
 <p class="Body">
-  <a name="2903"> </a>The architecture of JavaSpaces technology supports a simple transaction mechanism that allows multi-operation and/or multi-space updates to complete atomically. This is done using the two-phase commit model under the default transaction semantics, as defined in the package <code>net.jini.core.transaction</code> and described in the <a href="txn-spec.html"><em class="Emphasis">Jini Transaction Specification</em></a>.
+  <a id="2903"> </a>The architecture of JavaSpaces technology supports a simple transaction mechanism that allows multi-operation and/or multi-space updates to complete atomically. This is done using the two-phase commit model under the default transaction semantics, as defined in the package <code>net.jini.core.transaction</code> and described in the <a href="txn-spec.html"><em class="Emphasis">Jini Transaction Specification</em></a>.
 </p>
 <p class="Body">
-  <a name="2966"> </a>Entries written into a JavaSpaces service are governed by a lease, as defined in the package <code>net.jini.core.lease</code> and described in the <a href="lease-spec.html"><em class="Emphasis">Jini Distributed Leasing Specification</em></a>.
+  <a id="2966"> </a>Entries written into a JavaSpaces service are governed by a lease, as defined in the package <code>net.jini.core.lease</code> and described in the <a href="lease-spec.html"><em class="Emphasis">Jini Distributed Leasing Specification</em></a>.
 </p>
 <h5 class="Heading4">
-  <a name="1765"> </a>JS.1.1.1	 Distributed Persistence
+  <a id="1765"> </a>JS.1.1.1	 Distributed Persistence
 </h5>
 <p class="Body">
-  <a name="2397"> </a>Implementations of JavaSpaces technology provide a mechanism for storing a group of related objects and retrieving them based on a value-matching lookup for specified fields. This allows a JavaSpaces service to be used to store and retrieve objects on a remote system.
+  <a id="2397"> </a>Implementations of JavaSpaces technology provide a mechanism for storing a group of related objects and retrieving them based on a value-matching lookup for specified fields. This allows a JavaSpaces service to be used to store and retrieve objects on a remote system.
 </p>
 <h5 class="Heading4">
-  <a name="2399"> </a>JS.1.1.2	 Distributed Algorithms as Flows of Objects
+  <a id="2399"> </a>JS.1.1.2	 Distributed Algorithms as Flows of Objects
 </h5>
 <p class="Body">
-  <a name="1768"> </a>Many distributed algorithms can be modeled as a flow of objects between participants. This is different from the traditional way of approaching distributed computing, which is to create method-invocation-style protocols between participants. In this architecture's "flow of objects" approach, protocols are based on the movement of objects into and out of implementations of JavaSpaces technology.
+  <a id="1768"> </a>Many distributed algorithms can be modeled as a flow of objects between participants. This is different from the traditional way of approaching distributed computing, which is to create method-invocation-style protocols between participants. In this architecture's "flow of objects" approach, protocols are based on the movement of objects into and out of implementations of JavaSpaces technology.
 </p>
 <p class="Body">
-  <a name="1769"> </a>For example, a book-ordering system might look like this:
+  <a id="1769"> </a>For example, a book-ordering system might look like this:
 </p>
 <ul>
-  <li class="SmartList1"><a name="1770"> </a>A book buyer wants to buy 100 copies of a book. The buyer writes a request for bids into a particular public JavaSpaces service.<p>
-  <li class="SmartList1"><a name="1771"> </a>The broker runs a server that takes those requests out of the space and writes them into a JavaSpaces service for each book seller who registered with the broker for that service.<p>
-  <li class="SmartList1"><a name="1772"> </a>A server at each book seller removes the requests from its JavaSpaces service, presents the request to a human to prepare a bid, and writes the bid into the space specified in the book buyer's request for bids.<p>
-  <li class="SmartList1"><a name="30613"> </a>When the bidding period closes, the buyer takes all the bids from the space and presents them to a human to select the winning bid.
+  <li class="SmartList1"><a id="1770"> </a>A book buyer wants to buy 100 copies of a book. The buyer writes a request for bids into a particular public JavaSpaces service.<p>
+  <li class="SmartList1"><a id="1771"> </a>The broker runs a server that takes those requests out of the space and writes them into a JavaSpaces service for each book seller who registered with the broker for that service.<p>
+  <li class="SmartList1"><a id="1772"> </a>A server at each book seller removes the requests from its JavaSpaces service, presents the request to a human to prepare a bid, and writes the bid into the space specified in the book buyer's request for bids.<p>
+  <li class="SmartList1"><a id="30613"> </a>When the bidding period closes, the buyer takes all the bids from the space and presents them to a human to select the winning bid.
 </ul>
 <p class="Body">
-  <a name="30619"> </a>A method-invocation-style design would create particular remote interfaces for these interactions. With a "flow of objects" approach, only one interface is required: the <code>net.jini.space.JavaSpace</code> interface.
+  <a id="30619"> </a>A method-invocation-style design would create particular remote interfaces for these interactions. With a "flow of objects" approach, only one interface is required: the <code>net.jini.space.JavaSpace</code> interface.
 </p>
 <p class="Body">
-  <a name="30676"> </a>In general, the JavaSpaces application world looks like this:
+  <a id="30676"> </a>In general, the JavaSpaces application world looks like this:
 <p><CENTER>
 <img src="images/js-speca.gif" alt="explained in following paragraph" height="348" width="480">
 
 </CENTER></p>
 <p class="Body">
-  <a name="30679"> </a>Clients perform operations that map entries or templates onto JavaSpaces services. These can be singleton operations (as with the upper client), or contained in transactions (as with the lower client) so that all or none of the operations take place. A single client can interact with as many spaces as it needs to. Identities are accessed from the security subsystem and passed as parameters to method invocations. Notifications go to event catchers, which may be clients themselves or proxies for a client (such as a store-and-forward mailbox).
+  <a id="30679"> </a>Clients perform operations that map entries or templates onto JavaSpaces services. These can be singleton operations (as with the upper client), or contained in transactions (as with the lower client) so that all or none of the operations take place. A single client can interact with as many spaces as it needs to. Identities are accessed from the security subsystem and passed as parameters to method invocations. Notifications go to event catchers, which may be clients themselves or proxies for a client (such as a store-and-forward mailbox).
 </p>
 <h4 class="Heading3">
-  <a name="1840"> </a>JS.1.2	 Benefits
-</h3>
+  <a id="1840"> </a>JS.1.2	 Benefits
+</h4>
 <p class="Body">
-  <a name="30861"> </a>JavaSpaces services are tools for building distributed protocols. They are designed to work with applications that can model themselves as flows of objects through one or more servers. If your application can be modeled this way, JavaSpaces technology will provide many benefits.
+  <a id="30861"> </a>JavaSpaces services are tools for building distributed protocols. They are designed to work with applications that can model themselves as flows of objects through one or more servers. If your application can be modeled this way, JavaSpaces technology will provide many benefits.
 </p>
 <p class="Body">
-  <a name="1862"> </a>JavaSpaces services can provide a reliable distributed storage system for the objects. In the book-buying example, the designer of the system had to define the protocol for the participants and design the various kinds of entries that must be passed around. This effort is akin to designing the remote interfaces that an equivalent customized service would require. Both the JavaSpaces system solution and the customized solution would require someone to write the code that presented requests and bids to humans in a <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">GUI</span>. And in both systems, someone would have to write code to handle the seller's registrations of interest with the broker.
+  <a id="1862"> </a>JavaSpaces services can provide a reliable distributed storage system for the objects. In the book-buying example, the designer of the system had to define the protocol for the participants and design the various kinds of entries that must be passed around. This effort is akin to designing the remote interfaces that an equivalent customized service would require. Both the JavaSpaces system solution and the customized solution would require someone to write the code that presented requests and bids to humans in a <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">GUI</span>. And in both systems, someone would have to write code to handle the seller's registrations of interest with the broker.
 </p>
 <p class="Body">
-  <a name="1864"> </a>The server for the model that uses the JavaSpaces <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> would be implemented at that point.
+  <a id="1864"> </a>The server for the model that uses the JavaSpaces <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> would be implemented at that point.
 </p>
 <p class="Body">
-  <a name="1863"> </a>The customized system would need to implement the servers. These servers would have to handle concurrent access from multiple clients. Someone would need to design and implement a reliable storage strategy that guaranteed the entries written to the server would not be lost in an unrecoverable or undetectable way. If multiple bids needed to be made atomically, a distributed transaction system would have to be implemented.
+  <a id="1863"> </a>The customized system would need to implement the servers. These servers would have to handle concurrent access from multiple clients. Someone would need to design and implement a reliable storage strategy that guaranteed the entries written to the server would not be lost in an unrecoverable or undetectable way. If multiple bids needed to be made atomically, a distributed transaction system would have to be implemented.
 </p>
 <p class="Body">
-  <a name="1871"> </a>All these concerns are solved in JavaSpaces services. They handle concurrent access. They store and retrieve entries atomically. And they provide an implementation of the distributed transaction mechanism.
+  <a id="1871"> </a>All these concerns are solved in JavaSpaces services. They handle concurrent access. They store and retrieve entries atomically. And they provide an implementation of the distributed transaction mechanism.
 </p>
 <p class="Body">
-  <a name="1887"> </a>This is the power of the JavaSpaces technology architecture--many common needs are addressed in a simple platform that can be easily understood and used in powerful ways.
+  <a id="1887"> </a>This is the power of the JavaSpaces technology architecture--many common needs are addressed in a simple platform that can be easily understood and used in powerful ways.
 </p>
 <p class="Body">
-  <a name="1917"> </a>JavaSpaces services also help with data that would traditionally be stored in a file system, such as user preferences, e-mail messages, and images. Actually, this is not a different use of a JavaSpaces service. Such uses of a file system can equally be viewed as passing objects that contain state from one external object (the image editor) to another (the window system that uses the image as a screen background). And JavaSpaces services enhance this functionality because they store objects, not just data, so the image can have abstract behavior, not just information that must be interpreted by some external application(s).
+  <a id="1917"> </a>JavaSpaces services also help with data that would traditionally be stored in a file system, such as user preferences, e-mail messages, and images. Actually, this is not a different use of a JavaSpaces service. Such uses of a file system can equally be viewed as passing objects that contain state from one external object (the image editor) to another (the window system that uses the image as a screen background). And JavaSpaces services enhance this functionality because they store objects, not just data, so the image can have abstract behavior, not just information that must be interpreted by some external application(s).
 </p>
 <p class="Body">
-  <a name="2085"> </a>JavaSpaces services can provide distributed <em class="Emphasis">object</em> persistence with objects in the Java programming language. Because code written in the Java programming language is downloadable, entries can store objects whose behavior will be transmitted from the writer to the readers, just as in an <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> using Java technology. An entry in a space may, when fetched, cause some active behavior in the reading client. This is the benefit of storing objects, not just data, in an accessible repository for distributed cooperative computing.
+  <a id="2085"> </a>JavaSpaces services can provide distributed <em class="Emphasis">object</em> persistence with objects in the Java programming language. Because code written in the Java programming language is downloadable, entries can store objects whose behavior will be transmitted from the writer to the readers, just as in an <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> using Java technology. An entry in a space may, when fetched, cause some active behavior in the reading client. This is the benefit of storing objects, not just data, in an accessible repository for distributed cooperative computing.
 </p>
 <h4 class="Heading3">
-  <a name="2411"> </a>JS.1.3	 JavaSpaces Technology and Databases
-</h3>
+  <a id="2411"> </a>JS.1.3	 JavaSpaces Technology and Databases
+</h4>
 <p class="Body">
-  <a name="2428"> </a>A JavaSpaces service can store persistent data which is later searchable. But a JavaSpaces service is not a relational or object database. JavaSpaces services are designed to help solve problems in distributed computing, not to be used primarily as a data repository (although there are many data storage uses for JavaSpaces applications). Some important differences are:
+  <a id="2428"> </a>A JavaSpaces service can store persistent data which is later searchable. But a JavaSpaces service is not a relational or object database. JavaSpaces services are designed to help solve problems in distributed computing, not to be used primarily as a data repository (although there are many data storage uses for JavaSpaces applications). Some important differences are:
 </p>
 <ul>
-  <li class="SmartList1"><a name="2429"> </a>Relational databases understand the data they store and manipulate it directly via query languages. JavaSpaces services store entries that they understand only by type and the serialized form of each field. There are no general queries in the JavaSpaces application design, only "exact match" or "don't care" for a given field. You design your flow of objects so that this is sufficient and powerful.<p>
-  <li class="SmartList1"><a name="2435"> </a>Object databases provide an object oriented image of stored data that can be modified and used, nearly as if it were transient memory. JavaSpaces systems do not provide a nearly transparent persistent/transient layer, and work only on copies of entries.
+  <li class="SmartList1"><a id="2429"> </a>Relational databases understand the data they store and manipulate it directly via query languages. JavaSpaces services store entries that they understand only by type and the serialized form of each field. There are no general queries in the JavaSpaces application design, only "exact match" or "don't care" for a given field. You design your flow of objects so that this is sufficient and powerful.<p>
+  <li class="SmartList1"><a id="2435"> </a>Object databases provide an object oriented image of stored data that can be modified and used, nearly as if it were transient memory. JavaSpaces systems do not provide a nearly transparent persistent/transient layer, and work only on copies of entries.
 </ul>
 <p class="Body">
-  <a name="2446"> </a>These differences exist because JavaSpaces services are designed for a different purpose than either relational or object databases. A JavaSpaces service can be used for simple persistent storage, such as storing a user's preferences that can be looked up by the user's ID or name. JavaSpaces service functionality is somewhere between that of a filesystem and a database, but it is neither.
+  <a id="2446"> </a>These differences exist because JavaSpaces services are designed for a different purpose than either relational or object databases. A JavaSpaces service can be used for simple persistent storage, such as storing a user's preferences that can be looked up by the user's ID or name. JavaSpaces service functionality is somewhere between that of a filesystem and a database, but it is neither.
 </p>
 <h4 class="Heading3">
-  <a name="2427"> </a>JS.1.4	 JavaSpaces System Design and Linda<a href="#275577"><sup>3</sup></a> Systems
+  <a id="2427"> </a>JS.1.4	 JavaSpaces System Design and Linda<a href="#275577"><sup>3</sup></a> Systems
 </h4>
 <p class="Body">
-  <a name="2295"> </a>The JavaSpaces system design is strongly influenced by Linda systems, which support a similar model of entry-based shared concurrent processing. In <a href="js-spec.html#7438">Section&nbsp;JS.4.1, "Linda Systems"</a>, you will find several references that describe Linda-style systems.
+  <a id="2295"> </a>The JavaSpaces system design is strongly influenced by Linda systems, which support a similar model of entry-based shared concurrent processing. In <a href="js-spec.html#7438">Section&nbsp;JS.4.1, "Linda Systems"</a>, you will find several references that describe Linda-style systems.
 </p>
 <p class="Body">
-  <a name="2304"> </a>No knowledge of Linda systems is required to understand this specification. This section discusses the relationship of JavaSpaces systems with respect to Linda systems for the benefit of those already familiar with Linda programming. Other readers should feel free to skip ahead.
+  <a id="2304"> </a>No knowledge of Linda systems is required to understand this specification. This section discusses the relationship of JavaSpaces systems with respect to Linda systems for the benefit of those already familiar with Linda programming. Other readers should feel free to skip ahead.
 </p>
 <p class="Body">
-  <a name="2144"> </a>JavaSpaces systems are similar to Linda systems in that they store collections of information for future computation and are driven by value-based lookup. They differ in some important ways:
+  <a id="2144"> </a>JavaSpaces systems are similar to Linda systems in that they store collections of information for future computation and are driven by value-based lookup. They differ in some important ways:
 </p>
 <ul>
-  <li class="SmartList1"><a name="2210"> </a>Linda systems have not used rich typing. JavaSpaces systems take a deep concern with typing from the Java platform type-safe environment. In JavaSpaces systems, entries themselves, not just their fields, are typed--two different entries with the same field types but with different data types for the Java programming language are different entry types. For example, an entry that had a string and two double values could be either a named point or a named vector. In JavaSpaces systems these two entry types would have specific different classes for the Java platform, and templates for one type would never match the other, even if the values were compatible.<p>
-  <li class="SmartList1"><a name="2214"> </a>Entries are typed as objects in the Java programming language, so they may have methods associated with them. This provides a way of associating behavior with entries.<p>
-  <li class="SmartList1"><a name="2164"> </a>As another result of typed entries, JavaSpaces services allow matching of subtypes--a template match can return a type that is a subtype of the template type. This means that the read or take may return more states than anticipated. In combination with the previous point, this means that entry behavior can be polymorphic in the usual object-oriented style that the Java platform provides.<p>
-  <li class="SmartList1"><a name="2272"> </a>The fields of entries are objects in the Java programming language. Any object data type for the Java programming language can be used as a template for matching entry lookups as long as it has certain properties. This means that computing systems constructed using the JavaSpaces <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> are object-oriented from top to bottom, and behavior-based (agent-like) applications can use JavaSpaces services for co-ordination.<p>
-  <li class="SmartList1"><a name="2829"> </a>Most environments will have more than one JavaSpaces service. Most Linda tuple spaces have one tuple space for all cooperating threads. So transactions in the JavaSpaces system can span multiple spaces (and even non-JavaSpaces system transaction participants).<p>
-  <li class="SmartList1"><a name="2830"> </a>Entries written into a JavaSpaces service are leased. This helps keep the space free of debris left behind due to system crashes and network failures.<p>
-  <li class="SmartList1"><a name="2831"> </a>The JavaSpaces <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> does not provide an equivalent of "eval" because it would require the service to execute arbitrary computation on behalf of the client. Such a general compute service has its own large number of requirements (such as security and fairness).
+  <li class="SmartList1"><a id="2210"> </a>Linda systems have not used rich typing. JavaSpaces systems take a deep concern with typing from the Java platform type-safe environment. In JavaSpaces systems, entries themselves, not just their fields, are typed--two different entries with the same field types but with different data types for the Java programming language are different entry types. For example, an entry that had a string and two double values could be either a idd point or a idd vector. In JavaSpaces systems these two entry types would have specific different classes for the Java platform, and templates for one type would never match the other, even if the values were compatible.<p>
+  <li class="SmartList1"><a id="2214"> </a>Entries are typed as objects in the Java programming language, so they may have methods associated with them. This provides a way of associating behavior with entries.<p>
+  <li class="SmartList1"><a id="2164"> </a>As another result of typed entries, JavaSpaces services allow matching of subtypes--a template match can return a type that is a subtype of the template type. This means that the read or take may return more states than anticipated. In combination with the previous point, this means that entry behavior can be polymorphic in the usual object-oriented style that the Java platform provides.<p>
+  <li class="SmartList1"><a id="2272"> </a>The fields of entries are objects in the Java programming language. Any object data type for the Java programming language can be used as a template for matching entry lookups as long as it has certain properties. This means that computing systems constructed using the JavaSpaces <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> are object-oriented from top to bottom, and behavior-based (agent-like) applications can use JavaSpaces services for co-ordination.<p>
+  <li class="SmartList1"><a id="2829"> </a>Most environments will have more than one JavaSpaces service. Most Linda tuple spaces have one tuple space for all cooperating threads. So transactions in the JavaSpaces system can span multiple spaces (and even non-JavaSpaces system transaction participants).<p>
+  <li class="SmartList1"><a id="2830"> </a>Entries written into a JavaSpaces service are leased. This helps keep the space free of debris left behind due to system crashes and network failures.<p>
+  <li class="SmartList1"><a id="2831"> </a>The JavaSpaces <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> does not provide an equivalent of "eval" because it would require the service to execute arbitrary computation on behalf of the client. Such a general compute service has its own large number of requirements (such as security and fairness).
 </ul>
 <p class="Body">
-  <a name="2320"> </a>On the nomenclature side, the JavaSpaces technology <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> uses a more accessible set of terms than the traditional Linda terms. The term mappings are "entry" for "tuple," "value" for "actual," "wildcard" for "formal," "write" for "out," and "take" for "in." So the Linda sentence "When you `out' a tuple make sure that actuals and formals in `in' and `read' can do appropriate matching" would be translated to "When you write an entry make sure that values and wildcards in take and read can do appropriate matching."
+  <a id="2320"> </a>On the nomenclature side, the JavaSpaces technology <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">API</span> uses a more accessible set of terms than the traditional Linda terms. The term mappings are "entry" for "tuple," "value" for "actual," "wildcard" for "formal," "write" for "out," and "take" for "in." So the Linda sentence "When you `out' a tuple make sure that actuals and formals in `in' and `read' can do appropriate matching" would be translated to "When you write an entry make sure that values and wildcards in take and read can do appropriate matching."
 </p>
 <h4 class="Heading3">
-  <a name="1946"> </a>JS.1.5	 Goals and Requirements
+  <a id="1946"> </a>JS.1.5	 Goals and Requirements
 </h4>
 <p class="Body">
-  <a name="1950"> </a>The goals for the design of JavaSpaces technology are:
+  <a id="1950"> </a>The goals for the design of JavaSpaces technology are:
 </p>
 <ul>
-  <li class="SmartList1"><a name="1953"> </a>Provide a platform for designing distributed computing systems that simplifies the design and implementation of those systems.<p>
-  <li class="SmartList1"><a name="1972"> </a>The client side should have few classes, both to keep the client-side model simple and to make downloading of the client classes quick.<p>
-  <li class="SmartList1"><a name="2008"> </a>The client side should have a small footprint, because it will run on computers with limited local memory.<p>
-  <li class="SmartList1"><a name="2016"> </a>A variety of implementations should be possible, including relational database storage and object-oriented database storage.<p>
-  <li class="SmartList1"><a name="1989"> </a>It should be possible to create a replicated JavaSpaces service.
+  <li class="SmartList1"><a id="1953"> </a>Provide a platform for designing distributed computing systems that simplifies the design and implementation of those systems.<p>
+  <li class="SmartList1"><a id="1972"> </a>The client side should have few classes, both to keep the client-side model simple and to make downloading of the client classes quick.<p>
+  <li class="SmartList1"><a id="2008"> </a>The client side should have a small footprint, because it will run on computers with limited local memory.<p>
+  <li class="SmartList1"><a id="2016"> </a>A variety of implementations should be possible, including relational database storage and object-oriented database storage.<p>
+  <li class="SmartList1"><a id="1989"> </a>It should be possible to create a replicated JavaSpaces service.
 </ul>
 <p class="Body">
-  <a name="1998"> </a>The requirements for JavaSpaces application clients are:
+  <a id="1998"> </a>The requirements for JavaSpaces application clients are:
 </p>
 <ul>
-  <li class="SmartList1"><a name="2001"> </a>It must be possible to write a client purely in the Java programming language.<p>
-  <li class="SmartList1"><a name="2033"> </a>Clients must be oblivious to the implementation details of the service. The same entries and templates must work in the same ways no matter which implementation is used.
+  <li class="SmartList1"><a id="2001"> </a>It must be possible to write a client purely in the Java programming language.<p>
+  <li class="SmartList1"><a id="2033"> </a>Clients must be oblivious to the implementation details of the service. The same entries and templates must work in the same ways no matter which implementation is used.
 </ul>
 <h4 class="Heading3">
-  <a name="2063"> </a>JS.1.6	 Dependencies
+  <a id="2063"> </a>JS.1.6	 Dependencies
 </h4>
 <p class="Body">
-  <a name="2064"> </a>This document relies upon the following other specifications:
+  <a id="2064"> </a>This document relies upon the following other specifications:
 </p>
 <ul>
-  <li class="SmartList1"><a name="31963"> </a><em class="Emphasis">Java<font size="-1"><sup>TM</sup></font> Object Serialization Specification</em> <p>
-  <li class="SmartList1"><a name="2065"> </a><em class="Emphasis">Java<font size="-1"><sup>TM</sup></font> Remote Method Invocation Specification</em> <p>
-  <li class="SmartList1"><a name="31881"> </a><a href="entry-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Entry Specification</em></a><p>
-  <li class="SmartList1"><a name="31881"> </a><a href="event-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Distributed Events Specification</em></a><p>
-  <li class="SmartList1"><a name="31881"> </a><a href="lease-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Distributed Leasing Specification</em></a><p>
-  <li class="SmartList1"><a name="31881"> </a><a href="txn-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Transaction Specification</em></a><p>
+  <li class="SmartList1"><a id="31963"> </a><em class="Emphasis">Java<font size="-1"><sup>TM</sup></font> Object Serialization Specification</em> <p>
+  <li class="SmartList1"><a id="2065"> </a><em class="Emphasis">Java<font size="-1"><sup>TM</sup></font> Remote Method Invocation Specification</em> <p>
+  <li class="SmartList1"><a id="31881"> </a><a href="entry-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Entry Specification</em></a><p>
+  <li class="SmartList1"><a id="31881"> </a><a href="event-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Distributed Events Specification</em></a><p>
+  <li class="SmartList1"><a id="31881"> </a><a href="lease-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Distributed Leasing Specification</em></a><p>
+  <li class="SmartList1"><a id="31881"> </a><a href="txn-spec.html"><em class="Emphasis">Jini<font size="-1"><sup>TM</sup></font> Transaction Specification</em></a><p>
 </ul>
 
 <h3 class="Heading2">
-  <a name="7280"> </a>JS.2	 Operations
+  <a id="7280"> </a>JS.2	 Operations
 </h3>
 <p class="Body">
   There are four primary kinds of operations that you can invoke on a JavaSpaces service. Each operation has parameters that are entries, including some that are templates, which are a kind of entry. This chapter describes entries, templates, and the details of the operations, which are:
 </p>
 <ul>
-  <li class="SmartList1"><a name="7282"> </a><code>write</code>: Write the given entry into this JavaSpaces service.<p>
-  <li class="SmartList1"><a name="7283"> </a><code>read</code>: Read an entry from this JavaSpaces service that matches the given template.<p>
-  <li class="SmartList1"><a name="7284"> </a><code>take</code>: Read an entry from this JavaSpaces service that matches the given template, removing it from this space.<p>
-  <li class="SmartList1"><a name="7285"> </a><code>notify</code>: Notify a specified object when entries that match the given template are written into this JavaSpaces service.
+  <li class="SmartList1"><a id="7282"> </a><code>write</code>: Write the given entry into this JavaSpaces service.<p>
+  <li class="SmartList1"><a id="7283"> </a><code>read</code>: Read an entry from this JavaSpaces service that matches the given template.<p>
+  <li class="SmartList1"><a id="7284"> </a><code>take</code>: Read an entry from this JavaSpaces service that matches the given template, removing it from this space.<p>
+  <li class="SmartList1"><a id="7285"> </a><code>notify</code>: Notify a specified object when entries that match the given template are written into this JavaSpaces service.
 </ul>
 <p class="Body">
-  <a name="7286"> </a>As used in this document, the term "operation" refers to a single invocation of a method; for example, two different <code>take</code> operations may have different templates.
+  <a id="7286"> </a>As used in this document, the term "operation" refers to a single invocation of a method; for example, two different <code>take</code> operations may have different templates.
 </p>
 <h4 class="Heading3">
-  <a name="7287"> </a>JS.2.1	 Entries
+  <a id="7287"> </a>JS.2.1	 Entries
 </h4>
 <p class="Body">
-  <a name="30734"> </a>The types <code>Entry</code> and <code>UnusableEntryException</code> that are used in this specification are from the package <code>net.jini.core.entry</code> and are described in detail in the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>. In the terminology of that specification <code>write</code> is a store operation; <code>read</code> and <code>take</code> are combination search and fetch operations; and <code>notify</code> sets up repeated search operations as entries are written to the space.
+  <a id="30734"> </a>The types <code>Entry</code> and <code>UnusableEntryException</code> that are used in this specification are from the package <code>net.jini.core.entry</code> and are described in detail in the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>. In the terminology of that specification <code>write</code> is a store operation; <code>read</code> and <code>take</code> are combination search and fetch operations; and <code>notify</code> sets up repeated search operations as entries are written to the space.
 </p>
 <h4 class="Heading3">
-  <a name="7290"> </a>JS.2.2	 <code>net.jini.space.JavaSpace</code> 
+  <a id="7290"> </a>JS.2.2	 <code>net.jini.space.JavaSpace</code> 
 </h4>
 <p class="Body">
-  <a name="7291"> </a>All operations are invoked on an object that implements the <code>JavaSpace</code> interface. For example, the following code fragment would write an entry of type <code>AttrEntry</code> into the JavaSpaces service referred to by the identifier <code>space</code>:
+  <a id="7291"> </a>All operations are invoked on an object that implements the <code>JavaSpace</code> interface. For example, the following code fragment would write an entry of type <code>AttrEntry</code> into the JavaSpaces service referred to by the identifier <code>space</code>:
 
 <pre  class="Preformatted">JavaSpace space = getSpace();
 AttrEntry e = new AttrEntry();
-e.name = "Duke";
+e.id = "Duke";
 e.value = new GIFImage("dukeWave.gif");
 space.write(e, null, 60 * 60 * 1000);	 // one hour
 // lease is ignored -- one hour will be enough
 
 </pre>
 <p class="Body">
-  <a name="7293"> </a>The <code>JavaSpace</code> interface is:
+  <a id="7293"> </a>The <code>JavaSpace</code> interface is:
 </p>
 <pre  class="Preformatted">package net.jini.space;
 
@@ -287,22 +287,22 @@ public interface JavaSpace {
 
 </pre>
 <p class="Body">
-  <a name="10380"> </a>The <code>Transaction</code> and <code>TransactionException</code> types in the above signatures are imported from <code>net.jini.core.transaction</code>. The <code>Lease</code> type is imported from <code>net.jini.core.lease</code>. The <code>RemoteEventListener</code> and <code>EventRegistration</code> types are imported from <code>net.jini.core.event</code>.
+  <a id="10380"> </a>The <code>Transaction</code> and <code>TransactionException</code> types in the above signatures are imported from <code>net.jini.core.transaction</code>. The <code>Lease</code> type is imported from <code>net.jini.core.lease</code>. The <code>RemoteEventListener</code> and <code>EventRegistration</code> types are imported from <code>net.jini.core.event</code>.
 </p>
 <p class="Body">
-  <a name="7296"> </a>In all methods that have the parameter, <code>txn</code> may be <code>null</code>, which means that no <code>Transaction</code> object is managing the operation (see <a href="js-spec.html#7388">Section&nbsp;JS.3, "Transactions"</a>). 
+  <a id="7296"> </a>In all methods that have the parameter, <code>txn</code> may be <code>null</code>, which means that no <code>Transaction</code> object is managing the operation (see <a href="js-spec.html#7388">Section&nbsp;JS.3, "Transactions"</a>). 
 </p>
 <p class="Body">
-  <a name="30749"> </a>The <code>JavaSpace</code> interface is not a remote interface. Each implementation of a JavaSpaces service exports proxy objects that implement the <code>JavaSpace</code> interface locally on the client, talking to the actual JavaSpaces service through an implementation-specific interface. An implementation of any <code>JavaSpace</code> method may communicate with a remote JavaSpaces service to accomplish its goal; hence, each method throws <code>RemoteException</code> to allow for possible failures. Unless noted otherwise in this specification, when you invoke <code>JavaSpace</code> methods you should expect <code>RemoteExceptions</code> on method calls in the same cases in which you would expect them for methods invoked directly on an <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> remote reference. For example, invoking <code>sna
 pshot</code> might require talking to the remote JavaSpaces server, and so might get a <code>RemoteException</code> if the server crashes during the operation.
+  <a id="30749"> </a>The <code>JavaSpace</code> interface is not a remote interface. Each implementation of a JavaSpaces service exports proxy objects that implement the <code>JavaSpace</code> interface locally on the client, talking to the actual JavaSpaces service through an implementation-specific interface. An implementation of any <code>JavaSpace</code> method may communicate with a remote JavaSpaces service to accomplish its goal; hence, each method throws <code>RemoteException</code> to allow for possible failures. Unless noted otherwise in this specification, when you invoke <code>JavaSpace</code> methods you should expect <code>RemoteExceptions</code> on method calls in the same cases in which you would expect them for methods invoked directly on an <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> remote reference. For example, invoking <code>snaps
 hot</code> might require talking to the remote JavaSpaces server, and so might get a <code>RemoteException</code> if the server crashes during the operation.
 </p>
 <p class="Body">
-  <a name="7301"> </a>The details of each <code>JavaSpace</code> method are given in the sections that follow.
+  <a id="7301"> </a>The details of each <code>JavaSpace</code> method are given in the sections that follow.
 </p>
 <h5 class="Heading4">
-  <a name="7303"> </a>JS.2.2.1	 <code>InternalSpaceException</code> 
+  <a id="7303"> </a>JS.2.2.1	 <code>InternalSpaceException</code> 
 </h5>
 <p class="Body">
-  <a name="7304"> </a>The exception <code>InternalSpaceException</code> may be thrown by a JavaSpaces service that encounters an inconsistency in its own internal state or is unable to process a request because of internal limitations (such as storage space being exhausted). This exception is a subclass of <code>RuntimeException</code>. The exception has two constructors: one that takes a <code>String</code> description and another that takes a <code>String</code> and a nested exception; both constructors simply invoke the <code>RuntimeException</code> constructor that takes a <code>String</code> argument.
+  <a id="7304"> </a>The exception <code>InternalSpaceException</code> may be thrown by a JavaSpaces service that encounters an inconsistency in its own internal state or is unable to process a request because of internal limitations (such as storage space being exhausted). This exception is a subclass of <code>RuntimeException</code>. The exception has two constructors: one that takes a <code>String</code> description and another that takes a <code>String</code> and a nested exception; both constructors simply invoke the <code>RuntimeException</code> constructor that takes a <code>String</code> argument.
 </p>
 <pre  class="Preformatted">package net.jini.space;
 
@@ -317,108 +317,108 @@ public class InternalSpaceException exte
 
 </pre>
 <p class="Body">
-  <a name="27286"> </a>The <code>nestedException</code> field is the one passed to the second constructor, or <code>null</code> if the first constructor was used. The overridden <code>printStackTrace</code> methods print out the stack trace of the exception and, if <code>nestedException</code> is not <code>null</code>, print out that stack trace as well.
+  <a id="27286"> </a>The <code>nestedException</code> field is the one passed to the second constructor, or <code>null</code> if the first constructor was used. The overridden <code>printStackTrace</code> methods print out the stack trace of the exception and, if <code>nestedException</code> is not <code>null</code>, print out that stack trace as well.
 </p>
 <h4 class="Heading3">
-  <a name="7308"> </a>JS.2.3	 <code>write</code> 
+  <a id="7308"> </a>JS.2.3	 <code>write</code> 
 </h4>
 <p class="Body">
-  <a name="7309"> </a>A <code>write</code> places a copy of an entry into the given JavaSpaces service. The <code>Entry</code> passed to the <code>write</code> is not affected by the operation. Each <code>write</code> operation places a new entry into the specified space, even if the same <code>Entry</code> object is used in more than one <code>write</code>.
+  <a id="7309"> </a>A <code>write</code> places a copy of an entry into the given JavaSpaces service. The <code>Entry</code> passed to the <code>write</code> is not affected by the operation. Each <code>write</code> operation places a new entry into the specified space, even if the same <code>Entry</code> object is used in more than one <code>write</code>.
 </p>
 <p class="Body">
-  <a name="7310"> </a>Each <code>write</code> invocation returns a <code>Lease</code> object that is <code>lease</code> milliseconds long. If the requested time is longer than the space is willing to grant, you will get a lease with a reduced time. When the lease expires, the entry is removed from the space. An <code>IllegalArgumentException</code> will be thrown if the lease time requested is negative and not equal to <CODE>Lease.ANY</CODE>.
+  <a id="7310"> </a>Each <code>write</code> invocation returns a <code>Lease</code> object that is <code>lease</code> milliseconds long. If the requested time is longer than the space is willing to grant, you will get a lease with a reduced time. When the lease expires, the entry is removed from the space. An <code>IllegalArgumentException</code> will be thrown if the lease time requested is negative and not equal to <CODE>Lease.ANY</CODE>.
 </p>
 <p class="Body">
-  <a name="30767"> </a>If a <code>write</code> returns without throwing an exception, that entry is committed to the space, possibly within a transaction (see <a href="js-spec.html#7388">Section&nbsp;JS.3, "Transactions"</a>). If a <code>RemoteException</code> is thrown, the <code>write</code> may or may not have been successful. If any other exception is thrown, the entry was not written into the space.
+  <a id="30767"> </a>If a <code>write</code> returns without throwing an exception, that entry is committed to the space, possibly within a transaction (see <a href="js-spec.html#7388">Section&nbsp;JS.3, "Transactions"</a>). If a <code>RemoteException</code> is thrown, the <code>write</code> may or may not have been successful. If any other exception is thrown, the entry was not written into the space.
 </p>
 <p class="Body">
-  <a name="7315"> </a>Writing an entry into a space might generate notifications to registered objects (see <a href="js-spec.html#7346">Section&nbsp;JS.2.7, "<code>notify</code>"</a>).
+  <a id="7315"> </a>Writing an entry into a space might generate notifications to registered objects (see <a href="js-spec.html#7346">Section&nbsp;JS.2.7, "<code>notify</code>"</a>).
 </p>
 <h4 class="Heading3">
-  <a name="7320"> </a>JS.2.4	 <code>readIfExists</code> and <code>read</code>
+  <a id="7320"> </a>JS.2.4	 <code>readIfExists</code> and <code>read</code>
 </h4>
 <p class="Body">
-  <a name="7321"> </a>The two forms of the <code>read</code> request search the JavaSpaces service for an entry that matches the template provided as an <code>Entry</code>. If a match is found, a reference to a copy of the matching entry is returned. If no match is found, <code>null</code> is returned. Passing a <code>null</code> reference for the template will match any entry.
+  <a id="7321"> </a>The two forms of the <code>read</code> request search the JavaSpaces service for an entry that matches the template provided as an <code>Entry</code>. If a match is found, a reference to a copy of the matching entry is returned. If no match is found, <code>null</code> is returned. Passing a <code>null</code> reference for the template will match any entry.
 </p>
 <p class="Body">
-  <a name="7322"> </a>Any matching entry can be returned. Successive read requests with the same template in the same JavaSpaces service may or may not return equivalent objects, even if no intervening modifications have been made to the space. Each invocation of read may return a new object even if the same entry is matched in the JavaSpaces service.
+  <a id="7322"> </a>Any matching entry can be returned. Successive read requests with the same template in the same JavaSpaces service may or may not return equivalent objects, even if no intervening modifications have been made to the space. Each invocation of read may return a new object even if the same entry is matched in the JavaSpaces service.
 </p>
 <p class="Body">
-  <a name="7323"> </a>A <code>readIfExists</code> request will return a matching entry, or <code>null</code> if there is currently no matching entry in the space. If the only possible matches for the template have conflicting locks from one or more other transactions, the <code>timeout</code> value specifies how long the client is willing to wait for interfering transactions to settle before returning a value. If at the end of that time no value can be returned that would not interfere with transactional state, <code>null</code> is returned. Note that, due to the remote nature of JavaSpaces services, <code>read</code> and <code>readIfExists</code> may throw a <code>RemoteException</code> if the network or server fails prior to the timeout expiration
+  <a id="7323"> </a>A <code>readIfExists</code> request will return a matching entry, or <code>null</code> if there is currently no matching entry in the space. If the only possible matches for the template have conflicting locks from one or more other transactions, the <code>timeout</code> value specifies how long the client is willing to wait for interfering transactions to settle before returning a value. If at the end of that time no value can be returned that would not interfere with transactional state, <code>null</code> is returned. Note that, due to the remote nature of JavaSpaces services, <code>read</code> and <code>readIfExists</code> may throw a <code>RemoteException</code> if the network or server fails prior to the timeout expiration
 </p>
 <p class="Body">
-  <a name="7324"> </a>A <code>read</code> request acts like a <code>readIfExists</code> except that it will wait until a matching entry is found or until transactions settle, whichever is longer, up to the timeout period.
+  <a id="7324"> </a>A <code>read</code> request acts like a <code>readIfExists</code> except that it will wait until a matching entry is found or until transactions settle, whichever is longer, up to the timeout period.
 </p>
 <p class="Body">
-  <a name="31373"> </a>In both read methods, a timeout of <code>NO_WAIT</code> means to return immediately, with no waiting, which is equivalent to using a zero timeout. An <code>IllegalArgumentException</code> will be thrown if a negative timeout value is used.
+  <a id="31373"> </a>In both read methods, a timeout of <code>NO_WAIT</code> means to return immediately, with no waiting, which is equivalent to using a zero timeout. An <code>IllegalArgumentException</code> will be thrown if a negative timeout value is used.
 </p>
 <h4 class="Heading3">
-  <a name="31375"> </a>JS.2.5	 <code>takeIfExists</code> and <code>take</code>
+  <a id="31375"> </a>JS.2.5	 <code>takeIfExists</code> and <code>take</code>
 </h4>
 <p class="Body">
-  <a name="31227"> </a>The <code>take</code> requests perform exactly like the corresponding <code>read</code> requests (see <a href="js-spec.html#7320">Section&nbsp;JS.2.4, "<code>readIfExists</code> and <code>read</code>"</a>), except that the matching entry is removed from the space. Two <code>take</code> operations will never return copies of the same entry, although if two equivalent entries were in the JavaSpaces service the two <code>take</code> operations could return equivalent entries.
+  <a id="31227"> </a>The <code>take</code> requests perform exactly like the corresponding <code>read</code> requests (see <a href="js-spec.html#7320">Section&nbsp;JS.2.4, "<code>readIfExists</code> and <code>read</code>"</a>), except that the matching entry is removed from the space. Two <code>take</code> operations will never return copies of the same entry, although if two equivalent entries were in the JavaSpaces service the two <code>take</code> operations could return equivalent entries.
 </p>
 <p class="Body">
-  <a name="30790"> </a>If a <code>take</code> returns a non-<code>null</code> value, the entry has been removed from the space, possibly within a transaction (see <a href="js-spec.html#7388">Section&nbsp;JS.3, "Transactions"</a>). This modifies the claims to once-only retrieval: A <code>take</code> is considered to be successful only if all enclosing transactions commit successfully. If a <code>RemoteException</code> is thrown, the <code>take</code> may or may not have been successful. If an <code>UnusableEntryException</code> is thrown, the <code>take</code> removed the unusable entry from the space; the contents of the exception are as described in the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>. If any other exception is thrown, the <code>take</code> did not occur, and no entry was removed from the space.
+  <a id="30790"> </a>If a <code>take</code> returns a non-<code>null</code> value, the entry has been removed from the space, possibly within a transaction (see <a href="js-spec.html#7388">Section&nbsp;JS.3, "Transactions"</a>). This modifies the claims to once-only retrieval: A <code>take</code> is considered to be successful only if all enclosing transactions commit successfully. If a <code>RemoteException</code> is thrown, the <code>take</code> may or may not have been successful. If an <code>UnusableEntryException</code> is thrown, the <code>take</code> removed the unusable entry from the space; the contents of the exception are as described in the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>. If any other exception is thrown, the <code>take</code> did not occur, and no entry was removed from the space.
 </p>
 <p class="Body">
-  <a name="7336"> </a>With a <code>RemoteException</code>, an entry can be removed from a space and yet never returned to the client that performed the <code>take</code>, thus losing the entry in between. In circumstances in which this is unacceptable, the <code>take</code> can be wrapped inside a transaction that is committed by the client when it has the requested entry in hand.
+  <a id="7336"> </a>With a <code>RemoteException</code>, an entry can be removed from a space and yet never returned to the client that performed the <code>take</code>, thus losing the entry in between. In circumstances in which this is unacceptable, the <code>take</code> can be wrapped inside a transaction that is committed by the client when it has the requested entry in hand.
 </p>
 <h4 class="Heading3">
-  <a name="7338"> </a>JS.2.6	 <code>snapshot</code> 
+  <a id="7338"> </a>JS.2.6	 <code>snapshot</code> 
 </h4>
 <p class="Body">
-  <a name="7339"> </a>The process of serializing an entry for transmission to a JavaSpaces service will be identical if the same entry is used twice. This is most likely to be an issue with templates that are used repeatedly to search for entries with <code>read</code> or <code>take</code>. The client-side implementations of <code>read</code> and <code>take</code> cannot reasonably avoid this duplicated effort, since they have no efficient way of checking whether the same template is being used without intervening modification.
+  <a id="7339"> </a>The process of serializing an entry for transmission to a JavaSpaces service will be identical if the same entry is used twice. This is most likely to be an issue with templates that are used repeatedly to search for entries with <code>read</code> or <code>take</code>. The client-side implementations of <code>read</code> and <code>take</code> cannot reasonably avoid this duplicated effort, since they have no efficient way of checking whether the same template is being used without intervening modification.
 </p>
 <p class="Body">
-  <a name="30806"> </a>The <code>snapshot</code> method gives the JavaSpaces service implementor a way to reduce the impact of repeated use of the same entry. Invoking <code>snapshot</code> with an <code>Entry</code> will return another <code>Entry</code> object that contains a <em class="Emphasis">snapshot</em> of the original entry. Using the returned snapshot entry is equivalent to using the unmodified original entry in all operations on the same JavaSpaces service. Modifications to the original entry will not affect the snapshot. You can <code>snapshot</code> a <code>null</code> template; <code>snapshot</code> may or may not return <code>null</code> given a <code>null</code> template.
+  <a id="30806"> </a>The <code>snapshot</code> method gives the JavaSpaces service implementor a way to reduce the impact of repeated use of the same entry. Invoking <code>snapshot</code> with an <code>Entry</code> will return another <code>Entry</code> object that contains a <em class="Emphasis">snapshot</em> of the original entry. Using the returned snapshot entry is equivalent to using the unmodified original entry in all operations on the same JavaSpaces service. Modifications to the original entry will not affect the snapshot. You can <code>snapshot</code> a <code>null</code> template; <code>snapshot</code> may or may not return <code>null</code> given a <code>null</code> template.
 </p>
 <p class="Body">
-  <a name="30807"> </a>The entry returned from <code>snapshot</code> will be guaranteed equivalent to the original unmodified object only when used with the space. Using the snapshot with any other JavaSpaces service will generate an <code>IllegalArgumentException</code> unless the other space can use it because of knowledge about the JavaSpaces service that generated the snapshot. The snapshot will be a different object from the original, may or may not have the same hash code, and <code>equals</code> may or may not return <code>true</code> when invoked with the original object, even if the original object is unmodified.
+  <a id="30807"> </a>The entry returned from <code>snapshot</code> will be guaranteed equivalent to the original unmodified object only when used with the space. Using the snapshot with any other JavaSpaces service will generate an <code>IllegalArgumentException</code> unless the other space can use it because of knowledge about the JavaSpaces service that generated the snapshot. The snapshot will be a different object from the original, may or may not have the same hash code, and <code>equals</code> may or may not return <code>true</code> when invoked with the original object, even if the original object is unmodified.
 </p>
 <p class="Body">
-  <a name="7342"> </a>A snapshot is guaranteed to work only within the virtual machine in which it was generated. If a snapshot is passed to another virtual machine (for example, in a parameter of an <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> call), using it--even with the same JavaSpaces service--may generate an <code>IllegalArgumentException</code>.
+  <a id="7342"> </a>A snapshot is guaranteed to work only within the virtual machine in which it was generated. If a snapshot is passed to another virtual machine (for example, in a parameter of an <span style="color: #000000; font-size: 10pt; font-style: normal; font-weight: normal; text-decoration: none; text-transform: none; vertical-align: baseline">RMI</span> call), using it--even with the same JavaSpaces service--may generate an <code>IllegalArgumentException</code>.
 </p>
 <p class="Body">
-  <a name="7343"> </a>We expect that an implementation of JavaSpaces technology will return a specialized <code>Entry</code> object that represents a pre-serialized version of the object, either in the object itself or as an identifier for the entry that has been cached on the server. Although the client may cache the snapshot on the server, it must guarantee that the snapshot returned to the client code is always valid. The implementation may not throw any exception that indicates that the snapshot has become invalid because it has been evicted from a cache. An implementation that uses a server-side cache must therefore guarantee that the snapshot is valid as long as it is reachable (not garbage) in the client, such as by storing enough information in the client to be able to re-insert the snapshot into the server-side cache.
+  <a id="7343"> </a>We expect that an implementation of JavaSpaces technology will return a specialized <code>Entry</code> object that represents a pre-serialized version of the object, either in the object itself or as an identifier for the entry that has been cached on the server. Although the client may cache the snapshot on the server, it must guarantee that the snapshot returned to the client code is always valid. The implementation may not throw any exception that indicates that the snapshot has become invalid because it has been evicted from a cache. An implementation that uses a server-side cache must therefore guarantee that the snapshot is valid as long as it is reachable (not garbage) in the client, such as by storing enough information in the client to be able to re-insert the snapshot into the server-side cache.
 </p>
 <p class="Body">
-  <a name="7344"> </a>No other method returns a snapshot. Specifically, the return values of the <code>read</code> and <code>take</code> methods are not snapshots and are usable with any implementation of JavaSpaces technology.
+  <a id="7344"> </a>No other method returns a snapshot. Specifically, the return values of the <code>read</code> and <code>take</code> methods are not snapshots and are usable with any implementation of JavaSpaces technology.
 </p>
 <h4 class="Heading3">
-  <a name="7346"> </a>JS.2.7	 <code>notify</code> 
+  <a id="7346"> </a>JS.2.7	 <code>notify</code> 
 </h4>
 <p class="Body">
-  <a name="27483"> </a>A <code>notify</code> request registers interest in future incoming entries to the JavaSpaces service that match the specified template. Matching is done as it is for <code>read</code>. The <code>notify</code> method is a particular registration method under the <a href="event-spec.html"><em class="Emphasis">Jini Distributed Events Specification</em></a>. When matching entries are written, the specified <code>RemoteEventListener</code> will eventually be notified. When you invoke <code>notify</code> you provide an upper bound on the lease time, which is how long you want the registration to be remembered by the JavaSpaces service. The service decides the actual time for the lease. You will get an <code>IllegalArgumentException</code> if the lease time requested is not <code>Lease.ANY</code> and is negative. The lease time is expressed in the standard millisecond units, although actual lease times will usually be of much larger granularity. A lease time
  of <code>Lease.FOREVER</code> is a request for an indefinite lease; if the service chooses not to grant an indefinite lease, it will return a bounded (non-zero) lease. The final argument to the notify request is a <CODE>MarshaledObject</CODE> called the handback.
+  <a id="27483"> </a>A <code>notify</code> request registers interest in future incoming entries to the JavaSpaces service that match the specified template. Matching is done as it is for <code>read</code>. The <code>notify</code> method is a particular registration method under the <a href="event-spec.html"><em class="Emphasis">Jini Distributed Events Specification</em></a>. When matching entries are written, the specified <code>RemoteEventListener</code> will eventually be notified. When you invoke <code>notify</code> you provide an upper bound on the lease time, which is how long you want the registration to be remembered by the JavaSpaces service. The service decides the actual time for the lease. You will get an <code>IllegalArgumentException</code> if the lease time requested is not <code>Lease.ANY</code> and is negative. The lease time is expressed in the standard millisecond units, although actual lease times will usually be of much larger granularity. A lease time o
 f <code>Lease.FOREVER</code> is a request for an indefinite lease; if the service chooses not to grant an indefinite lease, it will return a bounded (non-zero) lease. The final argument to the notify request is a <CODE>MarshaledObject</CODE> called the handback.
 <p>
 Each notify returns a <CODE>net.jini.core.event.EventRegistration</CODE> object. When an object is written that matches the template supplied in the <CODE>notify</CODE> invocation, the listener's <CODE>notify</CODE> method is eventually invoked, with a <CODE>RemoteEvent</CODE> object.  The <CODE>RemoteEvent</CODE> object's <CODE>getID</CODE> method will return the same value returned by the <CODE>EventRegistration</CODE> object's <CODE>getID</CODE> method.  This value, the event ID, will be unique at least with respect to all other active event registrations on this JavaSpaces service with different templates or transactions.  The <CODE>RemoteEvent</CODE> object's <CODE>getSource</CODE> method will return a reference to the JavaSpaces service.  If the handback associated with the registration was non-<CODE>null</CODE>, the <CODE>RemoteEvent</CODE> object's <CODE>getRegistrationObject</CODE> method will return an object that is equivalent (in the sense of the <CODE>equals</CO
 DE> method) to the handback, otherwise this method will return <CODE>null</CODE>. The <CODE>RemoteEvent</CODE> object's <CODE>getSequenceNumber</CODE> method will return the sequence number assigned to this event.  Sequence numbers for a given event ID are strictly increasing. If there is no gap between two sequence numbers, no events have been missed; if there is a gap, events might (but might not) have been missed. For example, a gap might occur if the JavaSpaces service crashes, even if no events are lost due to the crash.
 </p>
 <p class="Body">
-  <a name="7349"> </a>If the transaction parameter is <code>null</code>, the listener will be notified when matching entries are written either under a <code>null</code> transaction or when a transaction commits. If an entry is written under a transaction and then taken under that same transaction before the transaction is committed, listeners registered under a <code>null</code> transaction will not be notified of that entry.
+  <a id="7349"> </a>If the transaction parameter is <code>null</code>, the listener will be notified when matching entries are written either under a <code>null</code> transaction or when a transaction commits. If an entry is written under a transaction and then taken under that same transaction before the transaction is committed, listeners registered under a <code>null</code> transaction will not be notified of that entry.
 </p>
 <p class="Body">
-  <a name="7350"> </a>If the transaction parameter is not <code>null</code>, the listener will be notified of matching entries written under that transaction in addition to the notifications it would receive under a <code>null</code> transaction. A <code>notify</code> made with a non-<code>null</code> transaction is implicitly dropped when the transaction completes.
+  <a id="7350"> </a>If the transaction parameter is not <code>null</code>, the listener will be notified of matching entries written under that transaction in addition to the notifications it would receive under a <code>null</code> transaction. A <code>notify</code> made with a non-<code>null</code> transaction is implicitly dropped when the transaction completes.
 </p>
 <p class="Body">
-  <a name="7351"> </a>The request specified by a successful <code>notify</code> is as persistent as the entries of the space. They will be remembered as long as an untaken entry would be, until the lease expires, or until any governing transaction completes, whichever is shorter.
+  <a id="7351"> </a>The request specified by a successful <code>notify</code> is as persistent as the entries of the space. They will be remembered as long as an untaken entry would be, until the lease expires, or until any governing transaction completes, whichever is shorter.
 </p>
 <p class="Body">
-  <a name="7352"> </a>The service will make a "best effort" attempt to deliver notifications. The service will retry at most until the notification request's lease expires. Notifications may be delivered in any order.
+  <a id="7352"> </a>The service will make a "best effort" attempt to deliver notifications. The service will retry at most until the notification request's lease expires. Notifications may be delivered in any order.
 </p>
 <p class="Body">
-  <a name="7353"> </a>See the <a href="event-spec.html"><em class="Emphasis">Jini Distributed Events Specification</em></a> for details on the event types.
+  <a id="7353"> </a>See the <a href="event-spec.html"><em class="Emphasis">Jini Distributed Events Specification</em></a> for details on the event types.
 </p>
 <h4 class="Heading3">
-  <a name="7354"> </a>JS.2.8	 Operation Ordering
+  <a id="7354"> </a>JS.2.8	 Operation Ordering
 </h4>
 <p class="Body">
-  <a name="7355"> </a>Operations on a space are unordered. The only view of operation order can be a thread's view of the order of the operations it performs. A view of inter-thread order can be imposed only by cooperating threads that use an application-specific protocol to prevent two or more operations being in progress at a single time on a single JavaSpaces service. Such means are outside the purview of this specification.
+  <a id="7355"> </a>Operations on a space are unordered. The only view of operation order can be a thread's view of the order of the operations it performs. A view of inter-thread order can be imposed only by cooperating threads that use an application-specific protocol to prevent two or more operations being in progress at a single time on a single JavaSpaces service. Such means are outside the purview of this specification.
 </p>
 <p class="Body">
-  <a name="7356"> </a>For example, given two threads <em class="Emphasis">T</em> and <em class="Emphasis">U</em>, if <em class="Emphasis">T</em> performs a <code>write</code> operation and <em class="Emphasis">U</em> performs a <code>read</code> with a template that would match the written entry, the <code>read</code> may not find the written entry even if the <code>write</code> returns before the <code>read</code>. Only if <em class="Emphasis">T</em> and <em class="Emphasis">U</em> cooperate to ensure that the <code>write</code> returns before the <code>read</code> commences would the <code>read</code> be ensured the opportunity to find the entry written by <em class="Emphasis">T</em> (although it still might not do so because of an intervening <code>take</code> from a third entity).
+  <a id="7356"> </a>For example, given two threads <em class="Emphasis">T</em> and <em class="Emphasis">U</em>, if <em class="Emphasis">T</em> performs a <code>write</code> operation and <em class="Emphasis">U</em> performs a <code>read</code> with a template that would match the written entry, the <code>read</code> may not find the written entry even if the <code>write</code> returns before the <code>read</code>. Only if <em class="Emphasis">T</em> and <em class="Emphasis">U</em> cooperate to ensure that the <code>write</code> returns before the <code>read</code> commences would the <code>read</code> be ensured the opportunity to find the entry written by <em class="Emphasis">T</em> (although it still might not do so because of an intervening <code>take</code> from a third entity).
 </p>
 <h4 class="Heading3">
-  <a name="7358"> </a>JS.2.9	 Serialized Form
+  <a id="7358"> </a>JS.2.9	 Serialized Form
 </h4>
 <CENTER>
 <table border="1" bordercolorlight="#FFFFFF" bordercolordark="#000000"
@@ -436,99 +436,346 @@ Each notify returns a <CODE>net.jini.cor
  </align> </tr>
 </table>
 </CENTER>
+<h5 class="Heading3">
+  <a id="7360"> </a>JS.2.10	 <code>JavaSpace05</code> 
+</h5>
+<p class="Body">
+  <a id="7361"> </a>The <code>JavaSpace05</code> interface extends the 
+  JavaSpace interface to provide methods that allow clients to perform batch 
+  operations on the space (which are generally more efficient than performing 
+  an equivalent set of singleton operations) and to more easily develop 
+  applications where a given Entry needs to be read by multiple clients. 
+  Implementations of the JavaSpace interface are not required to implement 
+  this interface.
+</p>
+<p class="Body">
+  <a id="300016"> </a>Unless otherwise noted, the effects of any invocation of a method defined by this interface must be visible to any operation on the space that is started after the invocation returns normally. Note, the effects of a method invocation that throws a RemoteException are not necessarily visible when the exception is thrown. 
+</p>
+<p class="Body">
+  <a id="300017"> </a>All of the methods of this interface take one or more Collections as arguments. Each such Collection must be treated as immutable by implementations and must not be changed by the client during the course of any method invocation to which they have been passed.
+</p>
+<p class="Body">
+  <a id="300018"> </a>The <code>JavaSpace05</code> interface is not a remote interface. Each implementation of this interface exports a proxy object that implements this interface local to the client. Each method of the interface takes as one of its arguments a Collection of Entry instances. The entries themselves must be serialized in accordance with the Jini Entry Specification and will not be altered by the call. Typically, the Collection holding the entries will not be serialized at all. If one of these entries can't be serialized, a MarshalException will be thrown. Aside from the handling of these Collection of Entry parameters, all methods defined by this interface otherwise obey normal Java(TM) Remote Method Invocation remote interface semantics. 
+</p>
 
+</pre>
+<p class="Body">
+  <a id="7362"> </a>The <code>JavaSpace05</code> interface is:
+</p>
+<pre  class="Preformatted">package net.jini.space;
 
+import java.rmi.*;
+import java.util.*
+import net.jini.core.event.*;
+import net.jini.core.transaction.*;
+import net.jini.core.lease.*;
+import net.jini.entry.*
 
+public interface JavaSpace05 extends JavaSpace {
+    public List write(List        entries,
+		      Transaction txn,
+		      List        leaseDurations)
+	throws TransactionException, RemoteException;
+    public Collection take(Collection  tmpls, 
+			   Transaction txn, 
+			   long        timeout, 
+			   long        maxEntries)
+	throws UnusableEntriesException, TransactionException,
+	       RemoteException;
+    public MatchSet contents(Collection  tmpls, 
+			     Transaction txn,
+			     long        leaseDuration, 
+			     long        maxEntries)
+	throws TransactionException, RemoteException;
+    public EventRegistration 
+	registerForAvailabilityEvent(Collection          tmpls, 
+				     Transaction         txn,
+				     boolean             visibilityOnly,
+				     RemoteEventListener listener,
+				     long                leaseDuration, 
+				     MarshalledObject    handback)
+	throws TransactionException, RemoteException;
+}
 
+</pre>
+<p class="Body">
+  <a id="7363"> </a>The details of each <code>JavaSpace05</code> method are given in the sections that follow.
+</p>
+<h5 class="Heading4">
+  <a id="300000"> </a>JS.2.10.1	 <code>MatchSet</code> 
+</h5>
+<p class="Body">
+  <a id="300001"> </a>The <code>MatchSet</code> interface is a collection of 
+  Entry instances to be incrementally returned from a JavaSpaces service. 
+  Some operations on a space must return more entries than can be conveniently 
+  returned by a single call, generally because returning all the entries in one 
+  result would consume too many resources in the client or introduce too much 
+  latency before the first entry could be processed. In these cases, match sets
+  are returned to incrementally return the necessary entries. A MatchSet 
+  instance is a proxy object that can be used to access a match set created 
+  by a space.
+</p>
+<p class="Body">
+  <a id="300012"> </a>Typically match sets are created by some factory method 
+  on the space (for example, JavaSpace05.contents) which returns a MatchSet 
+  instance that will serve as a proxy to the match set. The match set will 
+  initially contain some population of entries specified by the operation that 
+  created it. These entries can be retrieved by calling next. 
+  A successful call to next will remove the returned Entry from the match set. 
+  Match sets can end up in one of two terminal states, exhausted or invalidated.
+  Under what conditions a match set enters one of these states is specified by 
+  the operation that created it. An exhausted match set is empty and will have 
+  no more entries added. Calling next on an exhausted match set must always 
+  return null. Calling next on an invalidated match set may return a non-null 
+  value, or it may throw one of the allowed exceptions. In particular it may 
+  throw NoSuchObjectException to indicate that the match set has been 
+  invalidated. Once next throws a NoSuchObjectException, all future next 
+  calls on that instance must also throw NoSuchObjectException. Calling next 
+  on an invalidated match set must never return null. 
+  Implementations must not add entries to an invalidated match set.
+</p>
+<p class="Body">
+  <a id="300013"> </a>Between the time a match set is created and the time it reaches a terminal state, entries may be added by the space. However, an Entry that is removed by a next call must not be added back to a match set (though if there is a distinct but equivalent entry in the space it may be added). The space may also remove entries independent of next calls. The conditions under which entries will be removed independent of next calls or added after the initial creation of the match set are specified by the operation that created the match set. 
+</p>
+<p class="Body">
+  <a id="300014"> </a>If there is a possibility that a match set may become invalidated, it must be leased and an appropriate proxy must be returned by the getLease method. If there is no possibility that the match set will become invalidated, implementations should not lease the match set. If a match set is not leased, then getLease must return null. 
+</p>
+<p class="Body">
+  <a id="300015"> </a>An active lease on a match set serves as a hint to the space that the client is still interested in the match set, and as a hint to the client that the match set is still functioning. However, implementations are allowed to invalidate match sets associated with active leases and to unilaterally cancel leases associated with functioning match sets. If a match set is leased and the lease is active, implementations should, to the best of their ability, maintain the match set and not invalidate it. There are cases, however, where this may not be possible in particular, it is not expected that implementations will maintain match sets across crashes. If the lease expires or is canceled, an implementation should invalidate the match set. An implementation must unilaterally cancel a match set's lease if the match set is invalidated. An implementation may unilaterally cancel the lease at other times without necessarily invalidating the match set. Clients should 
 not assume that the resources associated with a leased match set will be freed if the match set reaches the exhausted state, and should instead cancel the lease. This interface is not a remote interface; though in general a MatchSet is a proxy for some remote match set, only the next method is considered to be a remote method, and as outlined in its description it deviates in a number of ways from normal Java(TM) Remote Method Invocation remote method semantics.
+</p>
+<pre  class="Preformatted">package net.jini.space;
+
+public interface MatchSet {
+    public Entry next() throws RemoteException, UnusableEntryException;
+    public Lease getLease();
+    public Entry getSnapshot();
+}
+</pre>
+<h5 class="Heading4">
+  <a id="300002"> </a>JS.2.10.2	 <code>MatchSet.next</code> 
+</h5>
+<p class="Body">
+  <a id="300003"> </a>Removes one <code>Entry</code> from the match set and returns a copy to the caller. Returns null if the match set is empty. The returned <code>Entry</code> must be unmarshalled in accordance with the <a href="entry-spec.html"><em class="Emphasis">Jini Entry Specification</em></a>.
+</p>
+<p class="Body">
+  <a id="300004"> </a>A given invocation of this method may perform remote communications, but generally the next method is not expected to have remote method constraints that can vary from invocation to invocation. Instead the set of constraints associated with the next method will be fixed at the time the match set was created, even if this object implements an interface like <code>RemoteMethodControl</code> that would otherwise allow the set of constraints associated with the next method to be altered.
+</p>

[... 311 lines stripped ...]


Mime
View raw message