river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jgr...@simulexinc.com
Subject RE: Fw: Re: Space/outrigger suggestions
Date Sat, 18 Dec 2010 09:26:11 GMT
Users are already capable of creating the problem case you outlined with the existing space
implementation, and adding generics to the javaspace methods doesn't make it worse.

The most compelling problem case I've thought of is this:

GenericizedEntry<T extends Serializable> implements Entry {
 T val = null;
}
space.read(new GenericizedEntry<String>());

The "null" would fetch results of all types, which contradicts the principle of least surprise,
and the generic would foul things up at runtime.

However, again, this is already something that can happen with spaces.   Unless the user were
to check both the top level type and underlying generic field before casting, the user would
make the same mistake upon casting.

On the other hand, if we assume the user were savvy enough to do the runtime check of both
the type and any generic fields... then we might as well also assume they're savvy enough
to use broadest available type if passing in a null field (in this case Serializable).   There
are not likely many who would recognize one problem but not the other.

If the user is going to be using generic-laden fields in their Entries, they need to have
a fair knowledge of generics and/or trust in whoever is providing the entries they are reading.
  The inclusion of generics in the interface methods will not change this, for good or ill.
  (For that matter, neither does usage of generics on our part exclude the possibility of
using raw types as a user.)

---

At this point, I still favor the idea of including generics in the interface.   Upon consideration
of these problem cases, we seem to already be facing the problems of type-erased generics
in the language without reaping any of the benefits.

I do, however, now fully see the need for a discussion of generic usage and expectations within
space documentation.   We need to do that whether or not generics are in the interface, because
those issues can already happen.

jamesG

-----Original Message-----
From: "Peter" <jini@zeus.net.au>
Sent: Saturday, December 18, 2010 3:11am
To: river-dev@incubator.apache.org
Subject: Fw: Re: Space/outrigger suggestions

if you have a field in an Entry declared:

public Collection<String> names;

In bytecode, because of erasure, its type is Collection, this means I can take from the javaspace
and set the field to contain a Collection that doesn't contain String's and the next time
your code accesses it, a ClassCastException will occur.

If your not using generics, you can check it's type before performing a type cast.


Mime
View raw message