river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Fw: Re: Space/outrigger suggestions
Date Mon, 20 Dec 2010 15:51:47 GMT
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 

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

View raw message