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, naturally. jamesG -----Original Message----- From: "Peter" <j...@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? Peter.
