On 12/19/2010 4:15 AM, Dan Creswell wrote:
This somewhat speaks to the problems we'd face as the result of two separate
compiles for two separate clients and runtime classloading. One dev
specifies an Entry:
Test<Integer, String>
Another specifies:
Test<String, Integer>
If we assume we match on Test instances ignoring the generics and only the
anId field is set, then each client could end up with an instance of Test
that doesn't fit with it's templated/specified at compile-time typing.
I think previously, Peter was alluding to the inclusion of Generics in the APIs
to promote the use of Generics by developers in this way. Clearly, whatever
change we make to JavaSpaces won't preclude this happening. We need to provide
some guidance documentation or something that says things like the following.
"When you use generics in remote applications, you need to understand that the
type of any Generic specified type is not considered by the type matching in
JavaSpaces. If you have a class defined as follows,
public class Test<T,K> extends Entry {
T one;
K two;
String someThing;
}
Then you should not use that as the primary type in your APIs. Instead, you
should consider making that class "abstract" so that it can not be instantiated
incorrectly, and then create sub-classes with bound types that your application
uses to make sure that the true generic typing is concretely defined. Something
as simple as the following would then be used as the class that your application
uses.
public class IntStrTest extends Test<Integer,String> {}
Thus, you can share the code and implementation details, and still know that the
Generic types are concretely defined by the class."
This is, at least what I try and stress and use. In many cases, adding generics
in this way will reduce some casting. But in cases like JavaSpaces APIs where
there are return value and argument type linear type requirements, then proposed
change in declaration can also remove casting and not introduce any additional
risk of type confusion. Your example, Dan happens to be possible and
problematic no matter which way the API works. The idea behind the change is to
simply dictate the returned values type so that casting is eliminated there.
We can't fix the problem with people putting non-concrete types into the space
without adding additional logic to EntryRep construction so that it collects
this information and the space utilizes it during matching. If we do it there,
then we are essentially changing the spec to require more specific type
matching. I'd say it's not a spec incompatible change to do that, but because
it might break some carefully crafted hacks that are possible now, we might need
to investigate more.
Gregg Wonderly
Gregg Wonderly
