As this question is probably a FAQ, I've copied Ken's mail to this page -- CeesDeGroot.

• From: Ken.Arnold@East.Sun.COM (Ken Arnold - SMI Software Development) Subject: JavaSpace iterators: why not? Date: 1 Aug 2000 23:19:28 +0200 Message-ID: < 200008011938.PAA00264@cocolat.East.Sun.COM>

We frequently get asked why the JavaSpace interface doesn't have an iterator. We've answered the questions piecemeal in various forms. I thought it was time to write it all down in one place for the benefit of future generations and historians ("Lack of Iterators: How JavaSpaces Caused the Downfall of Civilization As It Was Then Known (Such As It Was)"-).

As you will see, the answer comes in the form of multiple reasons, at various levels of design. This is typical -- design decisions often come from multiple varying directions.

So, in cascading order:

• The JavaSpace architecture is in the family of Linda-style tuple systems. Extensive experience with such systems has shown that iterators are not necessary to do the work that tuple spaces are designed to do. Tuple spaces are *not* designed to be databases. They are designed to make it easy to write loosely coupled multi-threaded systems in which work is done between the various threads. They are a work coordination tool, not a storage and analysis tool. [This is also why you don't find an SQL-level query language.]

By using Linda-style design patterns you can do work coordination without iterators. So we took this as "proof by example" that iterators are unnecessary in this kind of design. And we are vicious about unnecessary things in our designs -- "Off with their heads!"

• Distributed iterators are complex and subtle. There is a

literature on distributed iteration techniques. This is a serious complexity to impose on any system, of which some will be in the implementation but other complexity could be visible in the specification (and hence to any programmer using a space). Adding serious complexity requires serious justification. And (see above) we have the opposite of serious justification.

• There are many semantics that must be defined for space iterators.

How do iterators interact with transactions? Are they themselves transactionally secure? Are they snapshots that only see entries added before the iterator is created? Or snapshots that see any entry added until the first time the iterator thinks it has reached the end? Or should the "next" method block until an entry is available? Do iterators walk through a set of entries defined by (a) a template, (b) a time stamp or time range, (c) something else, or (d) all entries, filtering done by the user? What about entries that leave the space during iteration (is this allowed?)? Should a "taking iterator" be allowed? Should the iterator only return entries or other associated data (write time, lease, ...)? And I'm really just getting going here, folks...

We certainly could make some set of choices to give concrete answers to such questions. But given this plethora, how could we make sure that we made a reasonable set of choices? Or that *any* set of choices would be of value to a significant percentage of people who want it? Surely before we add something requiring a lot of both specification complexity and implementation complexity (see above) we should know that we're helping a more than trivial number of people.

In other words, maybe we can satisfy *your* needs. But how many other people want the same thing, when you really nail it down?

• Yeah, sure, we could have multiple iterators to make sure that

we satisfied (overall) some larger number of people. I suspect that you can guess what I'd say about this. This is the complexity problem (see above) amplified by purposeful action.

Remember, one of the things about the way we distribute this stuff is that you can prove us wrong. Create a subinterface that adds an iterator, define your iterator's semantics, and see what happens. With some experience of this sort you could make a case -- proof by example speaks volumes.

And if you think that the community can agree on some set of semantics that would be worth the complexity cost, a discussion on javaspaces-users might help work it out.

So there you have it. Now you can reference this letter in the archives to see our folly recorded.

-- KenArnold