Patricia Shanahan wrote:
James Grahn wrote:
It (finally) occurred to me that we can have our cake and eat it too
in this case.
We can have the sweet deliciousness of API symmetry and retain the
implementation advantages of remote iterator & collection by having
both take-multiple and contents return:
Iterable.
This would introduce more flexibility in the spec, allowing more
design decisions to be made by those implementing, while presenting a
uniform external return type to the users. (A relatively standard
one at that.)
When I was looking at the remote iterator earlier, I was thinking it
would probably be best to have it implement Iterator and probably
Iterable anyway.
The only potential sour note is that Iterable is a 1.5 interface.
So that's come up again.
We could define our own Iterable, in one of our packages, with the
same definition as java.util.Iterable.
However, it would not have the nice for-loop syntax, and we could
spend a lot of time building up workarounds for not being 1.5.
Patricia
The interesting part about a mixed distributed environment is that it is
possible to have a Service API that requires a particular java platform,
clients that cannot support that Service API, can't look it up. Also
earlier java / jini platforms that lookup a Service that provides a
proxy with later version bytecode will not be unmarshalled, this is
actually acceptable as part of the spec.
Because changing a Service API creates a new API, it is actually
distinct, clients using the earlier Service, will get service proxy's of
that type, while clients that look up the latter Service api will get
different service instances that have a different type.
It is best to use a different class name when we change a Service API
Interface.
Part of my interest in a modular build relates to the possibility of
handling platform dependencies.
Cheers,
Peter.
