as Dan can tell you, I have big problems with the JavaSpaces API because -- IMHO -- it feels totally un-natural to a Java developer.)
In respect of un-natural, I think "different" may be a better term.
Dan, your work is a great credit to the JINI community, and I know how much you like it and really believe in it. I was careful to add "IMHO" because "natural", "unnatural", etc. are all subjective, and none of us will ever have the last word on such a conversation ;-).
If all we ever do is use the same old idioms and the same old constructs, we're only ever going to get so much progress. As human beings we like the familiar and feel uncomfortable with things that take us away from it. However, it has often been shown that going outside of the comfort zone is what leads to improvement.
Of course, but I (IMHO) believe that the Javaspaces API was designed in spite of
existing standards and conventions. See:http://jroller.com/page/cpurdy?entry=the_seven_habits_of_highly2
(Some time when we talk, I'll expand on this some more. My opinions on this particular topic are actually more caustic than I am prepared to express in public.)
A Map may be a fantastic API for a cache but you're going to struggle to convince me that it's the best option in other areas such as grid.
A Javaspace is just a very limited Map that puts serious restrictions on its content. That's why a commercial implementation added the Map API to their space implementation, and that's why the Javaspaces API itself is getting more and more Map-like methods added to it.
Secondly, regarding "grids", our software addresses the data access problem for applications running in grid environments, hence we refer to it as a Data Grid.
I don't argue for a "best option". Instead, I look at the Map API as a good "black box" that allows grid-aware implementations to be "mounted" behind it. I think with a major revision the Javaspace API could be a good "black box" API too, and that's what I've been trying to get Sun to see (with no luck so far).
I wish you could see what our customers are doing in grid environments. We've got end-to-end algorithmic trading grids (marktet feed all the way through to execution and settlement). We provide the data backbones for some of the busiest networks in the world (e.g. equities trading, travel and logistics). We provide HA infrastructure for datacenter failover ("disaster recovery" / "continuancy planning") -- and it has proven to work (i.e. a customer's datacenter went down with no interruption to their real time grid systems running on our software).
Sure you can probably make it fit but is that the right choice?
I'm just curious what you like about the Javaspace API that you can't do more easily with a transactional Map that supports queries, locking, agent invocation, events and the new Java ConcurrentMap API?
Cameron PurdyTangosol Coherence
: Clustered Shared Memory for Java