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" <[email protected]>
Sent: Saturday, December 18, 2010 3:11am
To: [email protected]
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.
