river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <grahn...@gmail.com>
Subject Re: correctness, generics, and spaces
Date Thu, 02 Jun 2011 13:11:27 GMT
On Thu, Jun 2, 2011 at 3:06 AM, Peter Firmstone <jini@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

> 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

> Peter.

View raw message