BasicEventList accepts null for ReadWriteLock?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

BasicEventList accepts null for ReadWriteLock?

hbrands
Administrator
Hey guys,

it's not a big deal, but I just noticed that BasicEventList accepts a null ReadWriteLock
in its constructor without further action.
Is this intentional?
I think it should check that it's not null or create a new lock if it's null, just as it's done
for the publisher in AbstractEventList.

Thoughts?

Thanks,
Holger

Reply | Threaded
Open this post in threaded view
|

Re: BasicEventList accepts null for ReadWriteLock?

Rob Eden
Back in the old days, I think it was recommended that null be passed  
in if you were going to manage locking yourself. I don't know that  
that's a good idea anymore though.

Rob

On Feb 7, 2010, at 10:30 AM, Holger Brands  
<[hidden email]> wrote:

> Hey guys,
>
> it's not a big deal, but I just noticed that BasicEventList accepts  
> a null ReadWriteLock
> in its constructor without further action.
> Is this intentional?
> I think it should check that it's not null or create a new lock if  
> it's null, just as it's done
> for the publisher in AbstractEventList.
>
> Thoughts?
>
> Thanks,
> Holger
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BasicEventList accepts null for ReadWriteLock?

hbrands
Administrator
Hi Rob,

but this would imply, that you'd have to check each call to EventList.getReadWriteLock() for a null return value to be correct and safe. I can't imagine that anyone would like to do that ;-)

I'm in favour of creating a new lock when a null is passed in...

Holger

2010/2/7 Rob Eden <[hidden email]>
Back in the old days, I think it was recommended that null be passed in if you were going to manage locking yourself. I don't know that that's a good idea anymore though.

Rob


On Feb 7, 2010, at 10:30 AM, Holger Brands <[hidden email]> wrote:

Hey guys,

it's not a big deal, but I just noticed that BasicEventList accepts a null ReadWriteLock
in its constructor without further action.
Is this intentional?
I think it should check that it's not null or create a new lock if it's null, just as it's done
for the publisher in AbstractEventList.

Thoughts?

Thanks,
Holger


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: BasicEventList accepts null for ReadWriteLock?

Rob Eden
Oh agreed. I'm not saying this should still be done. Just that I think that's why it was that way historically.

Rob

On Feb 8, 2010, at 1:49 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

but this would imply, that you'd have to check each call to EventList.getReadWriteLock() for a null return value to be correct and safe. I can't imagine that anyone would like to do that ;-)

I'm in favour of creating a new lock when a null is passed in...

Holger

2010/2/7 Rob Eden <[hidden email]>
Back in the old days, I think it was recommended that null be passed in if you were going to manage locking yourself. I don't know that that's a good idea anymore though.

Rob


On Feb 7, 2010, at 10:30 AM, Holger Brands <[hidden email]> wrote:

Hey guys,

it's not a big deal, but I just noticed that BasicEventList accepts a null ReadWriteLock
in its constructor without further action.
Is this intentional?
I think it should check that it's not null or create a new lock if it's null, just as it's done
for the publisher in AbstractEventList.

Thoughts?

Thanks,
Holger


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: BasicEventList accepts null for ReadWriteLock?

hbrands
Administrator
I fixed this, finally.
I also added precondition checks to methods
ListEventAssembler#addListEventListener
ListEventAssembler#removeListEventListener
to fail fast if null is passed in.

For reference:
http://java.net/jira/browse/GLAZEDLISTS-534
http://java.net/jira/browse/GLAZEDLISTS-535

Holger

2010/2/9 Rob Eden <[hidden email]>
Oh agreed. I'm not saying this should still be done. Just that I think that's why it was that way historically.

Rob

On Feb 8, 2010, at 1:49 PM, Holger Brands <[hidden email]> wrote:

Hi Rob,

but this would imply, that you'd have to check each call to EventList.getReadWriteLock() for a null return value to be correct and safe. I can't imagine that anyone would like to do that ;-)

I'm in favour of creating a new lock when a null is passed in...

Holger

2010/2/7 Rob Eden <[hidden email][hidden email]>
Back in the old days, I think it was recommended that null be passed in if you were going to manage locking yourself. I don't know that that's a good idea anymore though.

Rob


On Feb 7, 2010, at 10:30 AM, Holger Brands <[hidden email][hidden email]> wrote:

Hey guys,

it's not a big deal, but I just noticed that BasicEventList accepts a null ReadWriteLock
in its constructor without further action.
Is this intentional?
I think it should check that it's not null or create a new lock if it's null, just as it's done
for the publisher in AbstractEventList.

Thoughts?

Thanks,
Holger


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email][hidden email]
For additional commands, e-mail: [hidden email][hidden email]