These are pretty much my feelings. Sim, yes, a branch would be good so we can play in for testing purposes. The code changes should be fairly small for studying impacts with the current impl as we are talking about changing the interface of JavaSpace/05 and probably MatchSet as well. In the case of MatchSet I think we would want it to be able to reflect its purpose with class level generics as it works with the required Entry type returned from JS05 methods. Do them all for testing and planning and give everyone a chance to check it out; at least so we can look at it and decide from there.
I'm thinking once we have looked at it from that perspective and there is some consensus, then we probably will want to talk about impact on the Jini use cases overall. These changes will probably require a separate package to allow for full compile time backward compatibility with the old API. Essentially by doing that the old API will remain in place and the new generic versions can live side by side. Thanks, Wade ================== Wade Chandler Software Engineer and Developer NetBeans Dream Team Member and Contributor http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org ----- Original Message ---- > From: "jgr...@simulexinc.com" <jgr...@simulexinc.com> > To: river-dev@incubator.apache.org > Sent: Sat, December 18, 2010 12:30:28 PM > Subject: Re: Fw: Re: Space/outrigger suggestions > > 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. > > >
