My point is that in its current form, Generics will compile unchecked casts into distributed code.
That is bad and makes it easy for me to continue to find issues caused by the lack of cast checks in client code resulting in uncaught ClassCastException's Recall that generics type checking is a static compiler cast check. Code that comes together dynamically at runtime has not had all generic generated bytecode casts checked by the compiler. If someone wants to solve the runtime cast check problem, to restore type safety, then that's a different story and a separate research topic, when somebody takes it up we can revisit Generics for outrigger when it has stabilised. Everything else is just a workaround. I don't see the point of introducing new api we will have to support for many years to come, based on workarounds and corner cases. It is not my intent to derail you or get into some sort of ego contest, I don't mean any disrespect, I just don't relish the additional work I'll have supporting all the issues created by adding partial Generic support and feel River threatened by it and compelled to strongly resist it. I have a vested interest in River and I value your participation in the project. People can add Generics to their Service API now, when they run into trouble, I don't have any responsibility to support it in any way. I won't stop you from using Generics in your code, perhaps the generics discussion can continue on the user list for parties interested in using a subset of Generics? Or it can continue in a thread for generics, this is the space outrigger suggestions thread. The findings can be added to the River wiki as an experimental feature, where people will expect problems, but it stays out of production code and it doesn't require me to make a committment to it. It will also be a valuable resource to direct peoples attention to whenever the topic of Generics pops up. The documentation effort has my support, but the addition of a Generic method to Outrigger doesn't. Sincerely, Peter. ----- Original message ----- > ----- Original Message ---- > > > From: Peter <j...@zeus.net.au> > > To: river-dev@incubator.apache.org > > Sent: Mon, December 20, 2010 5:38:05 PM > > Subject: Re: Fw: Re: Space/outrigger suggestions > > > > 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. > > > > Are you saying you check all fields of your returns? Either way you have an > error arise. You have some kind of an exceptional situation. Not sure how I > see > this as more of a DOS either way. It is service layer code, so of course you > are > going to code against those calls with a general catch...or should. Other than > that, just performing the cast there isn't going to be some code run, just the > exception raised. > > On the rest as it relates to generics, oh well, I believe this conversation > has > just run off the track into a lets just prove a point no matter what or > something else completely orthogonal to the reality. I don't believe the > generics use implies anything other than there are generics used in a given > aspect of the API. I think if one wants to use generics and does they are > going > to use them. Seeing them here doesn't change that, but of course that is my > opinion. I'll just leave it there, and have no interest in talking about > generics more regardless of what I do or do not know as I feel it has become a > waste of time. FWIW, I say we do as you suggest and move onto the rest of the > discussion without talking generics, and see how that goes. > > Wade
