"JavaSpaces tries to accomplish something rather different. Yes, JavaSpaces is data-driven. It is object-oriented in the sense that the entries have type and you can match subtypes, and that entry fields can be object types. But at some point, you get past objects in any system. At some point, you call a method with an integer value. In some languages that integer is still logically an object, but it doesn't contain other objects. At some point, you hit the bottom. JavaSpaces is a bottom point in the sense that it is a way to make an asynchronous method call. You can consider that the entry fields are like the parameters to the method call. The fact that those are data shouldn't bother you, because that is when you hit bottom," says Ken Arnold in this Artima.com interview:

http://www.artima.com/intv/decouple.html

"...But at some point, you get past objects in any system. At some point, you call a method with an integer value. ..."

This is a general design question, rather than JavaSpaces specific, but it's something I've been wondering about for a while:

Where do I draw that line? For example, I've written many methods that only need a String as parameter, e.g. "user name". I'm always in a dilema whether to make the parameter a simple String or the whole User object. The latter option appealedd both because it seemed more "Object-Oriented", and the signature seems more telling even if poor parameter names are chosen - that String could be anything but User is more clear. However, this could place more burden on clients and limit usability (some contexts might not have the whole User object). What if we change the example method to need 2 properties of a an object, or 5? What then? My guess (as I am writing this) is to decompose the the larger object into finer ones and have only the appropriate required finer object as parameter to the method. Any thoughts?

can we change the javaspace spec to garantee fifo?
another words, for any given match always return the oldest one. this would be great for fifo queues and alot of people need fifo queues for things like compute servers. also, i don't see any value for the spec to allow unorder match returning, except maybe to make implemention easier.

> Where do I draw that line? For example, I've written
> many methods that only need a String as parameter,
> e.g. "user name". I'm always in a dilema whether to
> make the parameter a simple String or the whole User
> object. The latter option appealedd both because it
> seemed more "Object-Oriented", and the signature
> seems more telling even if poor parameter names are
> chosen - that String could be anything but User is
> more clear. However, this could place more burden on
> clients and limit usability (some contexts might not
> have the whole User object). What if we change the
> example method to need 2 properties of a an object,
> or 5? What then? My guess (as I am writing this) is
> to decompose the the larger object into finer ones
> and have only the appropriate required finer object
> as parameter to the method. Any thoughts?

This is a good question. I was just recently debating with Matt Gerrans over whether a particular method parameter should be a String or a File. Actually, I think I had originally put a File in there and Matt was questioning my choice. We settled on String, because we figured it was simpler and more likely the form the user already had.

I wouldn't consider a User (or File) more "object-oriented" than String. A String is an object too.

One question I'd ask, now that I've heard Ken Arnold on the subject, is: "What form does the user most likely already have in hand?" That form would be the easiest for the user. But you usually can't be certain of the answer. Matt and I weren't sure that users would have Strings more often than File objects in hand, but we thought that was more likely. Ken talks about this question in Part I of his interview:

http://www.artima.com/intv/perfect.html

Another kind of value a more specific type may provide is making sure the data is correct. For example, a URL object, if it is not null, by definition represents a valid URL string, which can be retrieved via the toString or toExternalForm methods. Using URL in a method parameter helps users prevent mistakes, because they can't send you an invalid URL string (other than null).

The last point you raised reminds me of the advice a software manager once gave me, which was that if a type Zoo contains a Lion, a Tiger, a Bear, and a Zebra, but a method only needs the Zebra, then make the parameter type Zebra. If the method needs both a Lion and a Zebra, then probably have two method parameters, one Lion and one Zebra. But if the method needs three of the four animals, then just send the whole Zoo. At some point, in other words, it becomes clearer and easier to just send the whole Zoo, Even though the method does't actually need all the animals, you also want to keep the number of parameters in the method signature to a reasonable, user-friendly number.

Although I understand your point of not having an iterator implementation in Sun JavaSpace, I always thought Sun implementations would offer a reasonable framework for "basic operations" with an implementation class offering a reasonable service.
If it's hard for Sun's people to think of a good iterator framework, it can be hard for us too ;-) !
I'm trying to find a simple solution for different machines to share a set of objects in a javaspace with an effective and elegant algorithm : it's not really a simple solution that I've found...
May be the problem is JavaSpace has not been build to share things but to dispatch information.

> Although I understand your point of not having an iterator
> implementation in Sun JavaSpace, I always thought Sun
> implementations would offer a reasonable framework for
> "basic operations" with an implementation class offering a
> reasonable service.
> If it's hard for Sun's people to think of a good iterator
> framework, it can be hard for us too ;-) !
> I'm trying to find a simple solution for different
> machines to share a set of objects in a javaspace with an
> effective and elegant algorithm : it's not really a simple
> solution that I've found...
> May be the problem is JavaSpace has not been build to
> share things but to dispatch information.

That's correct.

To share information, you are looking for a clustered in-memory data store, like Tangosol Coherence -- see http://www.tangosol.com/coherence.jsp -- which is based on the JCache API instead of the space API.

Peace,

Cameron Purdy
Tangosol, Inc.

In the article, Ken Arnold stated that JavaSpaces is an adaptation of Linda. I don't quite understand why the JavaSpaces designers didn't provide a primitive like "eval" that is present in Linda.