river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: A non blocking (almost) DynamicPermissionCollection
Date Wed, 21 Dec 2011 05:27:51 GMT
Hmm,

You're right, the code is more readable with a cast ;)

A side effect of Generics being bolted on, hope they fix it some day.

Peter.

----- Original message -----
> On 12/19/2011 1:14 PM, Peter Firmstone wrote:
> > Gregg Wonderly wrote:
> > > On 12/18/2011 11:59 PM, Peter Firmstone wrote:
> > > >      @Override
> > > >      public boolean implies(Permission permission) {
> > > >              if ( ! cl.isInstance(permission)) return false;
> > > >              Permission [] p = perms.toArray(new Permission[0]);
//perms.size()
> > > > may change
> > >
> > > I not sure why you are using an empty Permission array here, and then
> > > looping  over it.  Is this from some other testing?
> > >
> > > Gregg
> > >
> > The collection is wrapped with a ConcurrentCollection's multi read, single
> > write wrapper, by passing a zero length array to the collection, it obtains a
> > read lock, the collection creates a new array, sized to suit the underlying
> > array, copy's the collection's contents into it and returns, releasing the
> > read lock, the operation is atomic.
> > If I did this, the call would acquire and release two read locks
> > consecutively, it wouldn't be atomic:
> >
> > Permission[] p  = perms.toArray(new Permission[perms.size()]);
> >
> > It's there to avoid a cast:
> >
> > Permission [] p = (Permission[]) perms.toArray();
>
> Okay, that make sense from a logic perspective.  It might be better to use the
> second version just to remove the distraction of trying to understand how a zero
> length array results in a non-zero length result.
>
> Your call, I'm not sure it really matters.
>
> Gregg


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