Michael McGrady wrote:
A more apt comparison would be to have a record outside the sq. package. That is akin to an entry being outside the spaces package.
Let's see, my example illustrated passing a String into an API that would store the string. How is that not parallel to JavaSpace.put()?
There are many dependencies that should be decoupled and many others that should not be decoupled, and your example of String in java.lang.* and java.sql.* is one.
That's my point. Some things are core to a system while others are core to a package/service. Entry is a Jini System class, not a JavaSpace only class.
I refer you back to my little list of reasons and ways to decouple and reasons and ways to increase the cohesiveness of classes. There are different types of dependencies. The decisions must be thought through and justified.
I'm still unexcited by your continuance in citing ignorance as our problem when you continue to announce that you know nothing about the details of Jini yet you are demanding that the details be changed to meet your ignorant viewpoint.
I've asked for examples of how the compatibility of a new JavaSpace API that used it's own Entry type would be compatible with the existing services and clients so the people could role out a new instance of JavaSpace without breaking their existing clients. Can you help me understand how that issue would be addressed. At some point, the rubber has to hit the road and things have to be possible.
Gregg Wonderly
