On Thu, Jun 2, 2011 at 3:06 AM, Peter Firmstone <j...@zeus.net.au> wrote: > Are you suggesting type safety is NOT a necessary language feature in > distributed code?
Not at all. However, type safety is not a feature which is the exclusive terrain of the compiler. With the force of sufficient reasoning, type safe code can be written without the compiler's explicit blessing. So my question is more along the lines of: why do you not consider these operations type safe? Are there any examples which violate the typing? > 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? How does it reflect on River that read and take will not return the type of the template for concerns of type safety, when the documentation says that they will? Is the documentation wrong? Is the fundamental approach wrong? How does it reflect on River that every use of a space requires a cast, making it feel increasingly antiquated in the post-1.5 world? > 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. What is the bigger picture you're concerned with? You don't believe that the JavaSpace API should be made generic (even if correct) until every River API is genericized? Or that the additional proviso on Entry classes will be unacceptable to the other APIs that use Entries? (I'll try to look for an example of this in the other uses of Entry, but given that the design predates Java 1.5, I don't expect to find any problems excluding a feature introduced in 1.5.) Type-safety is something that can be empirically disproven. An example wherein type safety is broken (especially if it's worse than before) will do just that. If, on the other hand, we're moving on to policy positions concerning the timing of updates to River APIs, let's have that discussion instead. > Peter. james
