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.
