In the past, I had thought it acceptable to use specific Generic types as Gregg
has explained and I have discussed this previously on the list.
But the more I consider the tradeoffs, the more I realise Generics are more
harmful than good for Service API.
Here's another issue:
In untrusted networks you can enforce DownloadPermission, this prevents
downloading code from untrusted sources.
In such an environment, you can interop with anyone who authenticates as
anybody safely, since you're only using local or trusted code. Introduce
Generics into Service API, now you've given an attacker a means to induce a
ClassCastException, using a reflective proxy, an effective poison pill DOS
attack, that can be used to attack multiple clients.
A cast is simple enough to do and I always check my casts.
This discussion, has given me reason to reflect, as a result, my position is I
no longer support the use of Generics in Service API. I previously took a more
liberal position of implementer beware.
If user developers avoid the use of Generics in their Service API and objects
transferred using Service API, distributed programming will be less complicated.
Note: A proxy can use generics in its private implementation, because it
doesn't cross compillation boundaries. The client is also free to use Generics
within it's impementation, as are local libraries, the service implementation,
etc.
I'm happy for people to continue discussing, studying and documenting the
effects of Generics in Service API's for their own learning, but at some point
soon, I'd like to see it separated from the reimplementation of outrigger so we
can get on with progress.
Peter.
----- Original message -----
> 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
