river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Fw: Re: Space/outrigger suggestions
Date Tue, 21 Dec 2010 05:11:38 GMT
My point is that in its current form, Generics will compile unchecked casts into distributed

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.



----- Original message -----
> ----- Original Message ----
> > From: Peter <jini@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message