river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: correctness, generics, and spaces
Date Thu, 02 Jun 2011 08:23:40 GMT
I have to agree with Peter on this.  It's easy to make a "good enough"
solution using generic, particularly if you're developing services within a
single safe environment.  E.g. At your company where all services are
written by people on your team and hosted on a private company subnet.

But River is bigger than that and needs to be able to cater for all usages,
such as those which aren't as cozy as the one above.  I'm particularly
guilty of forgetting that since my usage if River/Jini is limited to the

In my opinion, one of the things River needs to avoid is making changes that
*imply* safety even if provisos are placed in documentation somewhere.
since (correct use of) generic imply safety, we need to make sure our
implementation of them provides that safety, in all cases.

Like Peter, I don't want to sound discouraging, but we need to make sure any
implementation is the correct one, long term.

I look forward to reviewing your patch though!


On 2 Jun 2011 08:15, "Peter Firmstone" <jini@zeus.net.au> wrote:
> James Grahn wrote:
>> but I'd
>> appreciate some clarification as to what that objection is. I don't
>> believe that any annotations or fancier tools will be necessary.
> Are you suggesting type safety is NOT a necessary language feature in
> distributed code?
> By adding a Generic JavaSpace API to River it suggests that Generics
> work as expected in Services and uphold type safety rules.
> But is dropping type safety to eliminate some boilerplate code is an
> acceptable compromise?
> How do we tell developers when they develop their services using
> Generics, the static compile time safety guarantee of generics doesn't
> exist in dynamically loaded code? They will of course expect type safety
> so this may come as a shock to some, how will this reflect on River?
> The problem is that if we move forward now and support generics without
> type safety, it's going to be much harder to fix later.
> I think we need to investigate solutions implementing type safety with
> Generics in dynamic code. Then you can forget about your corner cases,
> they are symptoms of unsafe type conversions that will vanish with the
> right solution.
> I'm not saying don't use generics, please experiment, but they're not
> stable until type safety issues have been properly addressed. Until we
> address Generic type safety in dynamic code which Services are, we
> should say it's experimental.
> I don't wish to sound discouraging, but I think ignoring the bigger
> picture is not the solution for River, I acknowledge that in your
> particular case you have figured out work arounds with some corner cases
> to be avoided, but the compromises made may not be acceptable for other
> service implementations.
> I'm interested in OpenSpaces type safety, namely:
> *Generics Support* – developers can use generics to avoid unnecessary
> casting and make their interaction with the space more type-safe.
> How did they make OpenSpaces more type-safe using Generics?
> Peter.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message