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 17:30:28 GMT
I think perhaps there are two separate issues here.

Issue #1:
Should we use generics in javaspace methods?

Issue #2:
Should we aggressively typecheck within javaspace to prevent common errors when using generics
across serialization boundaries?

The second issue is largely independent of the first, given that users are already free to
use generics within their Entries, and have been able to do so since Java 1.5.

I think that the second issue is what Peter is pointing to.   It is much more complex than
the first, owing to type erasure, and carries a potential performance penalties.   

The second issue is still worth looking into, however, given that there is potential for malformed
objects to be inserted into javaspace, whether through accident or malicious intent.   I'm
not entirely certain how far we would get with ASM.   Without ASM, reflection would enable
us to do some of these checks, but not all.   Worth pondering, though.

Others may see more connections between the two issues than I do.   But my thinking is that
the use of generics in an API does not guarantee fully proper use in extreme circumstances.

Indeed, the problem that was pointed out using a collection within an Entry has its root in
the Collection and not the Entry; the problem is, in short, that a user of the generically
typed collection could change the reference using a raw type with incorrectly typed elements.
  If the Collections API does not guard against such behavior (resulting in a class cast exception
at runtime), perhaps we would also be okay if we let it slide.   Documentation would be important,


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

The main problem is we need to figure out a way to handle the unchecked type casts.

Any ideas for a handler?

If we check the bytecode for instanceof checks and type casts, using ASM, we could insert
a type check and a handler that throws a checked exception.

Perhaps it might be possible to do this with a reflective wrapper proxy, to wrap the exception
in a RemoteException, at least the client knows how to deal with it and the service api is
local code.

We'd need to research where the compiler weaves in the class casts.

Currently generics are not designed for mobile code, we need to figure out a robust way of
doing it, if we are to support it, for me it's much easier to just say generics aren't supported
in remote code for now.

Unless we can find a way to make Generics and mobile code consistently typesafe, it'll be
a nightmare to support.

Can we set up a place in skunk to experiment?


View raw message