subject:"Lock pattern"

Re: Lock pattern

2016-07-21 Thread Ralph Goers

What is a mismatch?

Things that are all AutoCloseable all used to have an instance of the object 
created and then make sure it was closed during a finally call.  Locks 
generally don’t work that way.  They are typically created when they object 
they reside in is created and are destroyed when the object itself is 
destroyed.  Trying to equate lock() with open() or create() and unlock() to 
close() is a mistake IMO.

Ralph

> On Jul 21, 2016, at 2:18 PM, Gary Gregory  wrote:
> 
> On Fri, Jun 24, 2016 at 11:44 AM, Paul Benedict  > wrote:
> That may be the one! Thanks for searching for it. I can't believe it's from 
> three years ago! :-) Anyway, it goes on for some time and provides good 
> arguments to consider from both sides.
> 
> The whole thing is a mismatch IMO. On the one hand we have a _language 
> feature_, the try-with-resources statement. On the other we have the 
> AutoCloseable/Closeable interfaces that seem to have a very narrow focus, 
> which works nicely for low level objects like streams and also for very 
> different higher-level abstractions like JDBC Connections and ResultSets. It 
> seems that Locks are usually also a lower-level gadget like a stream, even 
> lower than a stream in fact. I could of course implement a very heavy and 
> resource intensive Lock, so YMMV.
> 
> Gary
>  
> 
> Cheers,
> Paul
> 
> On Fri, Jun 24, 2016 at 4:10 AM, Gary Gregory  > wrote:
> On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas  > wrote:
> I''m sure I read somewhere that it was a deliberate choice not to make it, to 
> stop people using the very common pattern of creating the object in the try() 
> - which isn't much use for a lock. 
> 
> Here? 
> http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html 
> 
> 
> Gary
>  
> 
> 
> Greg
> -- 
> Sent from my iPhone
> 
> On 24 Jun 2016, at 00:45, Remko Popma  > wrote:
> 
>> Good idea! 
>> Maybe propose this for Java 9?
>> Looks very reasonable to me. 
>> 
>> Sent from my iPhone
>> 
>> On 2016/06/24, at 8:32, Gary Gregory > > wrote:
>> 
>>> I wonder if anyone knows why Lock is not AutoCloseable.
>>> 
>>> This:
>>> 
>>> public static boolean hasManager(final String name) {
>>> LOCK.lock();
>>> try {
>>> return MAP.containsKey(name);
>>> } finally {
>>> LOCK.unlock();
>>> }
>>> }
>>> 
>>> 
>>> Seems lame in comparison to:
>>> 
>>> public static boolean hasManager(final String name) {
>>> try (LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>> 
>>> Which, due to syntax really would be:
>>> 
>>> public static boolean hasManager(final String name) {
>>> try (Object o = LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>> 
>>> Just wonderin'...
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com  | 
>>> ggreg...@apache.org  
>>> Java Persistence with Hibernate, Second Edition 
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com  
>>> Home: http://garygregory.com/ 
>>> Tweet! http://twitter.com/GaryGregory 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-07-21 Thread Gary Gregory

On Fri, Jun 24, 2016 at 11:44 AM, Paul Benedict 
wrote:

> That may be the one! Thanks for searching for it. I can't believe it's
> from three years ago! :-) Anyway, it goes on for some time and provides
> good arguments to consider from both sides.
>

The whole thing is a mismatch IMO. On the one hand we have a _language
feature_, the try-with-resources statement. On the other we have the
AutoCloseable/Closeable interfaces that seem to have a very narrow focus,
which works nicely for low level objects like streams and also for very
different higher-level abstractions like JDBC Connections and ResultSets.
It seems that Locks are usually also a lower-level gadget like a stream,
even lower than a stream in fact. I could of course implement a very heavy
and resource intensive Lock, so YMMV.

Gary


>
> Cheers,
> Paul
>
> On Fri, Jun 24, 2016 at 4:10 AM, Gary Gregory 
> wrote:
>
>> On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas 
>> wrote:
>>
>>> I''m sure I read somewhere that it was a deliberate choice not to make
>>> it, to stop people using the very common pattern of creating the object in
>>> the try() - which isn't much use for a lock.
>>>
>>
>> Here?
>> http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html
>>
>> Gary
>>
>>
>>>
>>>
>>> Greg
>>> --
>>> Sent from my iPhone
>>>
>>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>>
>>> Good idea!
>>> Maybe propose this for Java 9?
>>> Looks very reasonable to me.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>>
>>> I wonder if anyone knows why Lock is not AutoCloseable.
>>>
>>> This:
>>>
>>> public static boolean hasManager(final String name) {
>>> LOCK.lock();
>>> try {
>>> return MAP.containsKey(name);
>>> } finally {
>>> LOCK.unlock();
>>> }
>>> }
>>>
>>>
>>> Seems lame in comparison to:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> Which, due to syntax really would be:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> Just wonderin'...
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-24 Thread Paul Benedict

That may be the one! Thanks for searching for it. I can't believe it's from
three years ago! :-) Anyway, it goes on for some time and provides good
arguments to consider from both sides.

Cheers,
Paul

On Fri, Jun 24, 2016 at 4:10 AM, Gary Gregory 
wrote:

> On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas 
> wrote:
>
>> I''m sure I read somewhere that it was a deliberate choice not to make
>> it, to stop people using the very common pattern of creating the object in
>> the try() - which isn't much use for a lock.
>>
>
> Here?
> http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html
>
> Gary
>
>
>>
>>
>> Greg
>> --
>> Sent from my iPhone
>>
>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>
>> Good idea!
>> Maybe propose this for Java 9?
>> Looks very reasonable to me.
>>
>> Sent from my iPhone
>>
>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>
>> I wonder if anyone knows why Lock is not AutoCloseable.
>>
>> This:
>>
>> public static boolean hasManager(final String name) {
>> LOCK.lock();
>> try {
>> return MAP.containsKey(name);
>> } finally {
>> LOCK.unlock();
>> }
>> }
>>
>>
>> Seems lame in comparison to:
>>
>> public static boolean hasManager(final String name) {
>> try (LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Which, due to syntax really would be:
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Just wonderin'...
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: Lock pattern

2016-06-24 Thread Matt Sicker

That thread makes me think we should make some jmh tests for this.

On 24 June 2016 at 04:10, Gary Gregory  wrote:

> On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas 
> wrote:
>
>> I''m sure I read somewhere that it was a deliberate choice not to make
>> it, to stop people using the very common pattern of creating the object in
>> the try() - which isn't much use for a lock.
>>
>
> Here?
> http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html
>
> Gary
>
>
>>
>>
>> Greg
>> --
>> Sent from my iPhone
>>
>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>
>> Good idea!
>> Maybe propose this for Java 9?
>> Looks very reasonable to me.
>>
>> Sent from my iPhone
>>
>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>
>> I wonder if anyone knows why Lock is not AutoCloseable.
>>
>> This:
>>
>> public static boolean hasManager(final String name) {
>> LOCK.lock();
>> try {
>> return MAP.containsKey(name);
>> } finally {
>> LOCK.unlock();
>> }
>> }
>>
>>
>> Seems lame in comparison to:
>>
>> public static boolean hasManager(final String name) {
>> try (LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Which, due to syntax really would be:
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Just wonderin'...
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker

Re: Lock pattern

2016-06-24 Thread Gary Gregory

On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas 
wrote:

> I''m sure I read somewhere that it was a deliberate choice not to make it,
> to stop people using the very common pattern of creating the object in the
> try() - which isn't much use for a lock.
>

Here?
http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html

Gary


>
>
> Greg
> --
> Sent from my iPhone
>
> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>
> Good idea!
> Maybe propose this for Java 9?
> Looks very reasonable to me.
>
> Sent from my iPhone
>
> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>
> I wonder if anyone knows why Lock is not AutoCloseable.
>
> This:
>
> public static boolean hasManager(final String name) {
> LOCK.lock();
> try {
> return MAP.containsKey(name);
> } finally {
> LOCK.unlock();
> }
> }
>
>
> Seems lame in comparison to:
>
> public static boolean hasManager(final String name) {
> try (LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Which, due to syntax really would be:
>
> public static boolean hasManager(final String name) {
> try (Object o = LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Just wonderin'...
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-24 Thread Gary Gregory

Please see the branch "AutoCloseableLock" for my experiment, look for usage
of the class AutoCloseableLock.

Gary

On Thu, Jun 23, 2016 at 8:58 PM, Matt Sicker  wrote:

> FWIW, I'm still interested in this AutoCloseableLock idea.
>
> On 23 June 2016 at 22:25, Gary Gregory  wrote:
>
>> Before you go on a dig, is the discussion thread you are looking for
>> arguing against creating such a gadget as an AutoCloseableLock? As in, it's
>> an aberration?
>>
>> Gary
>>
>> On Thu, Jun 23, 2016 at 7:49 PM, Paul Benedict 
>> wrote:
>>
>>> If my memory serves me right, there is a whole thread on OpenJDK message
>>> boards on this design. I will find it and send it, time permitting.
>>>
>>> On Jun 23, 2016 9:07 PM, "Matt Sicker"  wrote:
>>>
 Any locks that don't use wait/notify could be converted to Object
 monitors instead. Using the Lock interface works best combined with
 Conditions as it's more powerful than the basic stuff in Object.

 Also, if you need something serializable as a lock, you can apparently
 use Object[0] because an empty array of anything is serializable.

 On 23 June 2016 at 20:48, Gary Gregory  wrote:

> On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker  wrote:
>
>> I kind of hate to point this out, but what's wrong with this when
>> you're not using multiple condition variables?
>>
>> final Object lock = new Object();
>> synchronized (lock) {
>>   // ...
>> }
>>
>
> Considering that we use a lot of ReentrantLocks, does this apply? We
> cannot replace ReentrantLocks with Objects. Or is that what you are
> proposing? I'm guessing you are making a more general point that
> a AutoCloseableLock is not a generic replacement for synchronized blocks.
>
> Gary
>
>>
>> It auto-unlocks at the end, too.
>>
>> On 23 June 2016 at 19:35, Gary Gregory 
>> wrote:
>>
>>> On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory <
>>> garydgreg...@gmail.com> wrote:
>>>
 On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory <
 garydgreg...@gmail.com> wrote:

> Like this:
>
> public static boolean hasManager(final String name) {
> try (Object o = AutoCloseableLock.lock(LOCK)) {
> return MAP.containsKey(name);
> }
> }
>
> With a new class:
>
> public class AutoCloseableLock implements AutoCloseable {
>
> public static AutoCloseableLock lock(final Lock lock) {
> Objects.requireNonNull(lock, "lock");
> lock.lock();
> return new AutoCloseableLock(lock);
> }
>
> private final Lock lock;
>
> public AutoCloseableLock(final Lock lock) {
> this.lock = lock;
> }
>
> @Override
> public void close() {
> this.lock.unlock();
> }
>
> public void lock() {
> this.lock.lock();
> }
>

 You do not even need a lock() method.

>>>
>>> But let's say you do for GC-free reasons:
>>>
>>> public AutoCloseableLock lock() {
>>> this.lock.lock();
>>> return this;
>>> }
>>>
>>> to do:
>>>
>>> private AutoCloseableLock autoCloseableLock = new
>>> AutoCloseableLock(new ReentrantLock());
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = autoCloseableLock.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>>  Gary
>>>
>>> Gary

> }
>
> The pro is less code and less chance for errors, the con is that
> you create a new AutoCloseableLock for lock/unlock sites.
>
> Gary
>
> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker 
> wrote:
>
>> Sounds like an opportunity for a small Commons or independent
>> project. CloseableLock!
>>
>> On 23 June 2016 at 18:51, Greg Thomas 
>> wrote:
>>
>>> I''m sure I read somewhere that it was a deliberate choice not
>>> to make it, to stop people using the very common pattern of 
>>> creating the
>>> object in the try() - which isn't much use for a lock.
>>>
>>> Greg
>>> --
>>> Sent from my iPhone
>>>
>>> On 24 Jun 2016, at 00:45, Remko Popma 
>>> wrote:
>>>
>>> Good idea!
>>> Maybe propose this for Java 9?
>>> Looks very

Re: Lock pattern

2016-06-23 Thread Matt Sicker

FWIW, I'm still interested in this AutoCloseableLock idea.

On 23 June 2016 at 22:25, Gary Gregory  wrote:

> Before you go on a dig, is the discussion thread you are looking for
> arguing against creating such a gadget as an AutoCloseableLock? As in, it's
> an aberration?
>
> Gary
>
> On Thu, Jun 23, 2016 at 7:49 PM, Paul Benedict 
> wrote:
>
>> If my memory serves me right, there is a whole thread on OpenJDK message
>> boards on this design. I will find it and send it, time permitting.
>>
>> On Jun 23, 2016 9:07 PM, "Matt Sicker"  wrote:
>>
>>> Any locks that don't use wait/notify could be converted to Object
>>> monitors instead. Using the Lock interface works best combined with
>>> Conditions as it's more powerful than the basic stuff in Object.
>>>
>>> Also, if you need something serializable as a lock, you can apparently
>>> use Object[0] because an empty array of anything is serializable.
>>>
>>> On 23 June 2016 at 20:48, Gary Gregory  wrote:
>>>
 On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker  wrote:

> I kind of hate to point this out, but what's wrong with this when
> you're not using multiple condition variables?
>
> final Object lock = new Object();
> synchronized (lock) {
>   // ...
> }
>

 Considering that we use a lot of ReentrantLocks, does this apply? We
 cannot replace ReentrantLocks with Objects. Or is that what you are
 proposing? I'm guessing you are making a more general point that
 a AutoCloseableLock is not a generic replacement for synchronized blocks.

 Gary

>
> It auto-unlocks at the end, too.
>
> On 23 June 2016 at 19:35, Gary Gregory  wrote:
>
>> On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory > > wrote:
>>
>>> On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory <
>>> garydgreg...@gmail.com> wrote:
>>>
 Like this:

 public static boolean hasManager(final String name) {
 try (Object o = AutoCloseableLock.lock(LOCK)) {
 return MAP.containsKey(name);
 }
 }

 With a new class:

 public class AutoCloseableLock implements AutoCloseable {

 public static AutoCloseableLock lock(final Lock lock) {
 Objects.requireNonNull(lock, "lock");
 lock.lock();
 return new AutoCloseableLock(lock);
 }

 private final Lock lock;

 public AutoCloseableLock(final Lock lock) {
 this.lock = lock;
 }

 @Override
 public void close() {
 this.lock.unlock();
 }

 public void lock() {
 this.lock.lock();
 }

>>>
>>> You do not even need a lock() method.
>>>
>>
>> But let's say you do for GC-free reasons:
>>
>> public AutoCloseableLock lock() {
>> this.lock.lock();
>> return this;
>> }
>>
>> to do:
>>
>> private AutoCloseableLock autoCloseableLock = new
>> AutoCloseableLock(new ReentrantLock());
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = autoCloseableLock.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>>  Gary
>>
>> Gary
>>>
 }

 The pro is less code and less chance for errors, the con is that
 you create a new AutoCloseableLock for lock/unlock sites.

 Gary

 On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker 
 wrote:

> Sounds like an opportunity for a small Commons or independent
> project. CloseableLock!
>
> On 23 June 2016 at 18:51, Greg Thomas 
> wrote:
>
>> I''m sure I read somewhere that it was a deliberate choice not to
>> make it, to stop people using the very common pattern of creating the
>> object in the try() - which isn't much use for a lock.
>>
>> Greg
>> --
>> Sent from my iPhone
>>
>> On 24 Jun 2016, at 00:45, Remko Popma 
>> wrote:
>>
>> Good idea!
>> Maybe propose this for Java 9?
>> Looks very reasonable to me.
>>
>> Sent from my iPhone
>>
>> On 2016/06/24, at 8:32, Gary Gregory 
>> wrote:
>>
>> I wonder if anyone knows why Lock is not AutoCloseable.
>>
>> This:
>>
>> public static boolean hasManager(final String name) {
>>

Re: Lock pattern

2016-06-23 Thread Gary Gregory

Before you go on a dig, is the discussion thread you are looking for
arguing against creating such a gadget as an AutoCloseableLock? As in, it's
an aberration?

Gary

On Thu, Jun 23, 2016 at 7:49 PM, Paul Benedict  wrote:

> If my memory serves me right, there is a whole thread on OpenJDK message
> boards on this design. I will find it and send it, time permitting.
>
> On Jun 23, 2016 9:07 PM, "Matt Sicker"  wrote:
>
>> Any locks that don't use wait/notify could be converted to Object
>> monitors instead. Using the Lock interface works best combined with
>> Conditions as it's more powerful than the basic stuff in Object.
>>
>> Also, if you need something serializable as a lock, you can apparently
>> use Object[0] because an empty array of anything is serializable.
>>
>> On 23 June 2016 at 20:48, Gary Gregory  wrote:
>>
>>> On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker  wrote:
>>>
 I kind of hate to point this out, but what's wrong with this when
 you're not using multiple condition variables?

 final Object lock = new Object();
 synchronized (lock) {
   // ...
 }

>>>
>>> Considering that we use a lot of ReentrantLocks, does this apply? We
>>> cannot replace ReentrantLocks with Objects. Or is that what you are
>>> proposing? I'm guessing you are making a more general point that
>>> a AutoCloseableLock is not a generic replacement for synchronized blocks.
>>>
>>> Gary
>>>

 It auto-unlocks at the end, too.

 On 23 June 2016 at 19:35, Gary Gregory  wrote:

> On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory 
> wrote:
>
>> On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory > > wrote:
>>
>>> Like this:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = AutoCloseableLock.lock(LOCK)) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> With a new class:
>>>
>>> public class AutoCloseableLock implements AutoCloseable {
>>>
>>> public static AutoCloseableLock lock(final Lock lock) {
>>> Objects.requireNonNull(lock, "lock");
>>> lock.lock();
>>> return new AutoCloseableLock(lock);
>>> }
>>>
>>> private final Lock lock;
>>>
>>> public AutoCloseableLock(final Lock lock) {
>>> this.lock = lock;
>>> }
>>>
>>> @Override
>>> public void close() {
>>> this.lock.unlock();
>>> }
>>>
>>> public void lock() {
>>> this.lock.lock();
>>> }
>>>
>>
>> You do not even need a lock() method.
>>
>
> But let's say you do for GC-free reasons:
>
> public AutoCloseableLock lock() {
> this.lock.lock();
> return this;
> }
>
> to do:
>
> private AutoCloseableLock autoCloseableLock = new
> AutoCloseableLock(new ReentrantLock());
>
> public static boolean hasManager(final String name) {
> try (Object o = autoCloseableLock.lock()) {
> return MAP.containsKey(name);
> }
> }
>
>  Gary
>
> Gary
>>
>>> }
>>>
>>> The pro is less code and less chance for errors, the con is that you
>>> create a new AutoCloseableLock for lock/unlock sites.
>>>
>>> Gary
>>>
>>> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker 
>>> wrote:
>>>
 Sounds like an opportunity for a small Commons or independent
 project. CloseableLock!

 On 23 June 2016 at 18:51, Greg Thomas 
 wrote:

> I''m sure I read somewhere that it was a deliberate choice not to
> make it, to stop people using the very common pattern of creating the
> object in the try() - which isn't much use for a lock.
>
> Greg
> --
> Sent from my iPhone
>
> On 24 Jun 2016, at 00:45, Remko Popma 
> wrote:
>
> Good idea!
> Maybe propose this for Java 9?
> Looks very reasonable to me.
>
> Sent from my iPhone
>
> On 2016/06/24, at 8:32, Gary Gregory 
> wrote:
>
> I wonder if anyone knows why Lock is not AutoCloseable.
>
> This:
>
> public static boolean hasManager(final String name) {
> LOCK.lock();
> try {
> return MAP.containsKey(name);
> } finally {
> LOCK.unlock();
> }
> }
>
>
> Seems lame in comparison to:
>
> public

Re: Lock pattern

2016-06-23 Thread Paul Benedict

If my memory serves me right, there is a whole thread on OpenJDK message
boards on this design. I will find it and send it, time permitting.

On Jun 23, 2016 9:07 PM, "Matt Sicker"  wrote:

> Any locks that don't use wait/notify could be converted to Object monitors
> instead. Using the Lock interface works best combined with Conditions as
> it's more powerful than the basic stuff in Object.
>
> Also, if you need something serializable as a lock, you can apparently use
> Object[0] because an empty array of anything is serializable.
>
> On 23 June 2016 at 20:48, Gary Gregory  wrote:
>
>> On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker  wrote:
>>
>>> I kind of hate to point this out, but what's wrong with this when you're
>>> not using multiple condition variables?
>>>
>>> final Object lock = new Object();
>>> synchronized (lock) {
>>>   // ...
>>> }
>>>
>>
>> Considering that we use a lot of ReentrantLocks, does this apply? We
>> cannot replace ReentrantLocks with Objects. Or is that what you are
>> proposing? I'm guessing you are making a more general point that
>> a AutoCloseableLock is not a generic replacement for synchronized blocks.
>>
>> Gary
>>
>>>
>>> It auto-unlocks at the end, too.
>>>
>>> On 23 June 2016 at 19:35, Gary Gregory  wrote:
>>>
 On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory 
 wrote:

> On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory 
> wrote:
>
>> Like this:
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = AutoCloseableLock.lock(LOCK)) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> With a new class:
>>
>> public class AutoCloseableLock implements AutoCloseable {
>>
>> public static AutoCloseableLock lock(final Lock lock) {
>> Objects.requireNonNull(lock, "lock");
>> lock.lock();
>> return new AutoCloseableLock(lock);
>> }
>>
>> private final Lock lock;
>>
>> public AutoCloseableLock(final Lock lock) {
>> this.lock = lock;
>> }
>>
>> @Override
>> public void close() {
>> this.lock.unlock();
>> }
>>
>> public void lock() {
>> this.lock.lock();
>> }
>>
>
> You do not even need a lock() method.
>

 But let's say you do for GC-free reasons:

 public AutoCloseableLock lock() {
 this.lock.lock();
 return this;
 }

 to do:

 private AutoCloseableLock autoCloseableLock = new
 AutoCloseableLock(new ReentrantLock());

 public static boolean hasManager(final String name) {
 try (Object o = autoCloseableLock.lock()) {
 return MAP.containsKey(name);
 }
 }

  Gary

 Gary
>
>> }
>>
>> The pro is less code and less chance for errors, the con is that you
>> create a new AutoCloseableLock for lock/unlock sites.
>>
>> Gary
>>
>> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker 
>> wrote:
>>
>>> Sounds like an opportunity for a small Commons or independent
>>> project. CloseableLock!
>>>
>>> On 23 June 2016 at 18:51, Greg Thomas 
>>> wrote:
>>>
 I''m sure I read somewhere that it was a deliberate choice not to
 make it, to stop people using the very common pattern of creating the
 object in the try() - which isn't much use for a lock.

 Greg
 --
 Sent from my iPhone

 On 24 Jun 2016, at 00:45, Remko Popma 
 wrote:

 Good idea!
 Maybe propose this for Java 9?
 Looks very reasonable to me.

 Sent from my iPhone

 On 2016/06/24, at 8:32, Gary Gregory 
 wrote:

 I wonder if anyone knows why Lock is not AutoCloseable.

 This:

 public static boolean hasManager(final String name) {
 LOCK.lock();
 try {
 return MAP.containsKey(name);
 } finally {
 LOCK.unlock();
 }
 }


 Seems lame in comparison to:

 public static boolean hasManager(final String name) {
 try (LOCK.lock()) {
 return MAP.containsKey(name);
 }
 }

 Which, due to syntax really would be:

 public static boolean hasManager(final String name) {
 try (Object o = LOCK.lock()) {
 return MAP.containsKey(name);

Re: Lock pattern

2016-06-23 Thread Matt Sicker

Any locks that don't use wait/notify could be converted to Object monitors
instead. Using the Lock interface works best combined with Conditions as
it's more powerful than the basic stuff in Object.

Also, if you need something serializable as a lock, you can apparently use
Object[0] because an empty array of anything is serializable.

On 23 June 2016 at 20:48, Gary Gregory  wrote:

> On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker  wrote:
>
>> I kind of hate to point this out, but what's wrong with this when you're
>> not using multiple condition variables?
>>
>> final Object lock = new Object();
>> synchronized (lock) {
>>   // ...
>> }
>>
>
> Considering that we use a lot of ReentrantLocks, does this apply? We
> cannot replace ReentrantLocks with Objects. Or is that what you are
> proposing? I'm guessing you are making a more general point that
> a AutoCloseableLock is not a generic replacement for synchronized blocks.
>
> Gary
>
>>
>> It auto-unlocks at the end, too.
>>
>> On 23 June 2016 at 19:35, Gary Gregory  wrote:
>>
>>> On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory 
>>> wrote:
>>>
 On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory 
 wrote:

> Like this:
>
> public static boolean hasManager(final String name) {
> try (Object o = AutoCloseableLock.lock(LOCK)) {
> return MAP.containsKey(name);
> }
> }
>
> With a new class:
>
> public class AutoCloseableLock implements AutoCloseable {
>
> public static AutoCloseableLock lock(final Lock lock) {
> Objects.requireNonNull(lock, "lock");
> lock.lock();
> return new AutoCloseableLock(lock);
> }
>
> private final Lock lock;
>
> public AutoCloseableLock(final Lock lock) {
> this.lock = lock;
> }
>
> @Override
> public void close() {
> this.lock.unlock();
> }
>
> public void lock() {
> this.lock.lock();
> }
>

 You do not even need a lock() method.

>>>
>>> But let's say you do for GC-free reasons:
>>>
>>> public AutoCloseableLock lock() {
>>> this.lock.lock();
>>> return this;
>>> }
>>>
>>> to do:
>>>
>>> private AutoCloseableLock autoCloseableLock = new
>>> AutoCloseableLock(new ReentrantLock());
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = autoCloseableLock.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>>  Gary
>>>
>>> Gary

> }
>
> The pro is less code and less chance for errors, the con is that you
> create a new AutoCloseableLock for lock/unlock sites.
>
> Gary
>
> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker  wrote:
>
>> Sounds like an opportunity for a small Commons or independent
>> project. CloseableLock!
>>
>> On 23 June 2016 at 18:51, Greg Thomas 
>> wrote:
>>
>>> I''m sure I read somewhere that it was a deliberate choice not to
>>> make it, to stop people using the very common pattern of creating the
>>> object in the try() - which isn't much use for a lock.
>>>
>>> Greg
>>> --
>>> Sent from my iPhone
>>>
>>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>>
>>> Good idea!
>>> Maybe propose this for Java 9?
>>> Looks very reasonable to me.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>>
>>> I wonder if anyone knows why Lock is not AutoCloseable.
>>>
>>> This:
>>>
>>> public static boolean hasManager(final String name) {
>>> LOCK.lock();
>>> try {
>>> return MAP.containsKey(name);
>>> } finally {
>>> LOCK.unlock();
>>> }
>>> }
>>>
>>>
>>> Seems lame in comparison to:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> Which, due to syntax really would be:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> Just wonderin'...
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action

Re: Lock pattern

2016-06-23 Thread Gary Gregory

On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker  wrote:

> I kind of hate to point this out, but what's wrong with this when you're
> not using multiple condition variables?
>
> final Object lock = new Object();
> synchronized (lock) {
>   // ...
> }
>

Considering that we use a lot of ReentrantLocks, does this apply? We cannot
replace ReentrantLocks with Objects. Or is that what you are proposing? I'm
guessing you are making a more general point that a AutoCloseableLock is
not a generic replacement for synchronized blocks.

Gary

>
> It auto-unlocks at the end, too.
>
> On 23 June 2016 at 19:35, Gary Gregory  wrote:
>
>> On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory 
>> wrote:
>>
>>> On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory 
>>> wrote:
>>>
 Like this:

 public static boolean hasManager(final String name) {
 try (Object o = AutoCloseableLock.lock(LOCK)) {
 return MAP.containsKey(name);
 }
 }

 With a new class:

 public class AutoCloseableLock implements AutoCloseable {

 public static AutoCloseableLock lock(final Lock lock) {
 Objects.requireNonNull(lock, "lock");
 lock.lock();
 return new AutoCloseableLock(lock);
 }

 private final Lock lock;

 public AutoCloseableLock(final Lock lock) {
 this.lock = lock;
 }

 @Override
 public void close() {
 this.lock.unlock();
 }

 public void lock() {
 this.lock.lock();
 }

>>>
>>> You do not even need a lock() method.
>>>
>>
>> But let's say you do for GC-free reasons:
>>
>> public AutoCloseableLock lock() {
>> this.lock.lock();
>> return this;
>> }
>>
>> to do:
>>
>> private AutoCloseableLock autoCloseableLock = new
>> AutoCloseableLock(new ReentrantLock());
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = autoCloseableLock.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>>  Gary
>>
>> Gary
>>>
 }

 The pro is less code and less chance for errors, the con is that you
 create a new AutoCloseableLock for lock/unlock sites.

 Gary

 On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker  wrote:

> Sounds like an opportunity for a small Commons or independent project.
> CloseableLock!
>
> On 23 June 2016 at 18:51, Greg Thomas  wrote:
>
>> I''m sure I read somewhere that it was a deliberate choice not to
>> make it, to stop people using the very common pattern of creating the
>> object in the try() - which isn't much use for a lock.
>>
>> Greg
>> --
>> Sent from my iPhone
>>
>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>
>> Good idea!
>> Maybe propose this for Java 9?
>> Looks very reasonable to me.
>>
>> Sent from my iPhone
>>
>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>
>> I wonder if anyone knows why Lock is not AutoCloseable.
>>
>> This:
>>
>> public static boolean hasManager(final String name) {
>> LOCK.lock();
>> try {
>> return MAP.containsKey(name);
>> } finally {
>> LOCK.unlock();
>> }
>> }
>>
>>
>> Seems lame in comparison to:
>>
>> public static boolean hasManager(final String name) {
>> try (LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Which, due to syntax really would be:
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Just wonderin'...
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> Matt Sicker 
>



 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 
 JUnit in Action, Second Edition 
 Spring Batch in Action 
 Blog: http://garygregory.wordpress.com
 Home:

Re: Lock pattern

2016-06-23 Thread Matt Sicker

I kind of hate to point this out, but what's wrong with this when you're
not using multiple condition variables?

final Object lock = new Object();
synchronized (lock) {
  // ...
}

It auto-unlocks at the end, too.

On 23 June 2016 at 19:35, Gary Gregory  wrote:

> On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory 
> wrote:
>
>> On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory 
>> wrote:
>>
>>> Like this:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = AutoCloseableLock.lock(LOCK)) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> With a new class:
>>>
>>> public class AutoCloseableLock implements AutoCloseable {
>>>
>>> public static AutoCloseableLock lock(final Lock lock) {
>>> Objects.requireNonNull(lock, "lock");
>>> lock.lock();
>>> return new AutoCloseableLock(lock);
>>> }
>>>
>>> private final Lock lock;
>>>
>>> public AutoCloseableLock(final Lock lock) {
>>> this.lock = lock;
>>> }
>>>
>>> @Override
>>> public void close() {
>>> this.lock.unlock();
>>> }
>>>
>>> public void lock() {
>>> this.lock.lock();
>>> }
>>>
>>
>> You do not even need a lock() method.
>>
>
> But let's say you do for GC-free reasons:
>
> public AutoCloseableLock lock() {
> this.lock.lock();
> return this;
> }
>
> to do:
>
> private AutoCloseableLock autoCloseableLock = new
> AutoCloseableLock(new ReentrantLock());
>
> public static boolean hasManager(final String name) {
> try (Object o = autoCloseableLock.lock()) {
> return MAP.containsKey(name);
> }
> }
>
>  Gary
>
> Gary
>>
>>> }
>>>
>>> The pro is less code and less chance for errors, the con is that you
>>> create a new AutoCloseableLock for lock/unlock sites.
>>>
>>> Gary
>>>
>>> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker  wrote:
>>>
 Sounds like an opportunity for a small Commons or independent project.
 CloseableLock!

 On 23 June 2016 at 18:51, Greg Thomas  wrote:

> I''m sure I read somewhere that it was a deliberate choice not to make
> it, to stop people using the very common pattern of creating the object in
> the try() - which isn't much use for a lock.
>
> Greg
> --
> Sent from my iPhone
>
> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>
> Good idea!
> Maybe propose this for Java 9?
> Looks very reasonable to me.
>
> Sent from my iPhone
>
> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>
> I wonder if anyone knows why Lock is not AutoCloseable.
>
> This:
>
> public static boolean hasManager(final String name) {
> LOCK.lock();
> try {
> return MAP.containsKey(name);
> } finally {
> LOCK.unlock();
> }
> }
>
>
> Seems lame in comparison to:
>
> public static boolean hasManager(final String name) {
> try (LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Which, due to syntax really would be:
>
> public static boolean hasManager(final String name) {
> try (Object o = LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Just wonderin'...
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


 --
 Matt Sicker 

>>>
>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java

Re: Lock pattern

2016-06-23 Thread Gary Gregory

On Thu, Jun 23, 2016 at 4:58 PM, Gary Gregory 
wrote:

> On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory 
> wrote:
>
>> Like this:
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = AutoCloseableLock.lock(LOCK)) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> With a new class:
>>
>> public class AutoCloseableLock implements AutoCloseable {
>>
>> public static AutoCloseableLock lock(final Lock lock) {
>> Objects.requireNonNull(lock, "lock");
>> lock.lock();
>> return new AutoCloseableLock(lock);
>> }
>>
>> private final Lock lock;
>>
>> public AutoCloseableLock(final Lock lock) {
>> this.lock = lock;
>> }
>>
>> @Override
>> public void close() {
>> this.lock.unlock();
>> }
>>
>> public void lock() {
>> this.lock.lock();
>> }
>>
>
> You do not even need a lock() method.
>

But let's say you do for GC-free reasons:

public AutoCloseableLock lock() {
this.lock.lock();
return this;
}

to do:

private AutoCloseableLock autoCloseableLock = new AutoCloseableLock(new
ReentrantLock());

public static boolean hasManager(final String name) {
try (Object o = autoCloseableLock.lock()) {
return MAP.containsKey(name);
}
}

 Gary

Gary
>
>> }
>>
>> The pro is less code and less chance for errors, the con is that you
>> create a new AutoCloseableLock for lock/unlock sites.
>>
>> Gary
>>
>> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker  wrote:
>>
>>> Sounds like an opportunity for a small Commons or independent project.
>>> CloseableLock!
>>>
>>> On 23 June 2016 at 18:51, Greg Thomas  wrote:
>>>
 I''m sure I read somewhere that it was a deliberate choice not to make
 it, to stop people using the very common pattern of creating the object in
 the try() - which isn't much use for a lock.

 Greg
 --
 Sent from my iPhone

 On 24 Jun 2016, at 00:45, Remko Popma  wrote:

 Good idea!
 Maybe propose this for Java 9?
 Looks very reasonable to me.

 Sent from my iPhone

 On 2016/06/24, at 8:32, Gary Gregory  wrote:

 I wonder if anyone knows why Lock is not AutoCloseable.

 This:

 public static boolean hasManager(final String name) {
 LOCK.lock();
 try {
 return MAP.containsKey(name);
 } finally {
 LOCK.unlock();
 }
 }


 Seems lame in comparison to:

 public static boolean hasManager(final String name) {
 try (LOCK.lock()) {
 return MAP.containsKey(name);
 }
 }

 Which, due to syntax really would be:

 public static boolean hasManager(final String name) {
 try (Object o = LOCK.lock()) {
 return MAP.containsKey(name);
 }
 }

 Just wonderin'...

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 
 JUnit in Action, Second Edition 
 Spring Batch in Action 
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory


>>>
>>>
>>> --
>>> Matt Sicker 
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-23 Thread Gary Gregory

On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas 
wrote:

> I''m sure I read somewhere that it was a deliberate choice not to make it,
> to stop people using the very common pattern of creating the object in the
> try() - which isn't much use for a lock.
>

It feels like there is a discrepancy between the narrow AutoCloseable use
case of "close me", and the more general try-with-resources which feels
more about do/undo, start/stop, being/end-type of pattern.

Gary

>
>
> Greg
> --
> Sent from my iPhone
>
> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>
> Good idea!
> Maybe propose this for Java 9?
> Looks very reasonable to me.
>
> Sent from my iPhone
>
> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>
> I wonder if anyone knows why Lock is not AutoCloseable.
>
> This:
>
> public static boolean hasManager(final String name) {
> LOCK.lock();
> try {
> return MAP.containsKey(name);
> } finally {
> LOCK.unlock();
> }
> }
>
>
> Seems lame in comparison to:
>
> public static boolean hasManager(final String name) {
> try (LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Which, due to syntax really would be:
>
> public static boolean hasManager(final String name) {
> try (Object o = LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Just wonderin'...
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-23 Thread Gary Gregory

On Thu, Jun 23, 2016 at 4:56 PM, Gary Gregory 
wrote:

> Like this:
>
> public static boolean hasManager(final String name) {
> try (Object o = AutoCloseableLock.lock(LOCK)) {
> return MAP.containsKey(name);
> }
> }
>
> With a new class:
>
> public class AutoCloseableLock implements AutoCloseable {
>
> public static AutoCloseableLock lock(final Lock lock) {
> Objects.requireNonNull(lock, "lock");
> lock.lock();
> return new AutoCloseableLock(lock);
> }
>
> private final Lock lock;
>
> public AutoCloseableLock(final Lock lock) {
> this.lock = lock;
> }
>
> @Override
> public void close() {
> this.lock.unlock();
> }
>
> public void lock() {
> this.lock.lock();
> }
>

You do not even need a lock() method.

Gary

> }
>
> The pro is less code and less chance for errors, the con is that you
> create a new AutoCloseableLock for lock/unlock sites.
>
> Gary
>
> On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker  wrote:
>
>> Sounds like an opportunity for a small Commons or independent project.
>> CloseableLock!
>>
>> On 23 June 2016 at 18:51, Greg Thomas  wrote:
>>
>>> I''m sure I read somewhere that it was a deliberate choice not to make
>>> it, to stop people using the very common pattern of creating the object in
>>> the try() - which isn't much use for a lock.
>>>
>>> Greg
>>> --
>>> Sent from my iPhone
>>>
>>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>>
>>> Good idea!
>>> Maybe propose this for Java 9?
>>> Looks very reasonable to me.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>>
>>> I wonder if anyone knows why Lock is not AutoCloseable.
>>>
>>> This:
>>>
>>> public static boolean hasManager(final String name) {
>>> LOCK.lock();
>>> try {
>>> return MAP.containsKey(name);
>>> } finally {
>>> LOCK.unlock();
>>> }
>>> }
>>>
>>>
>>> Seems lame in comparison to:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> Which, due to syntax really would be:
>>>
>>> public static boolean hasManager(final String name) {
>>> try (Object o = LOCK.lock()) {
>>> return MAP.containsKey(name);
>>> }
>>> }
>>>
>>> Just wonderin'...
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>
>>
>> --
>> Matt Sicker 
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-23 Thread Gary Gregory

Like this:

public static boolean hasManager(final String name) {
try (Object o = AutoCloseableLock.lock(LOCK)) {
return MAP.containsKey(name);
}
}

With a new class:

public class AutoCloseableLock implements AutoCloseable {

public static AutoCloseableLock lock(final Lock lock) {
Objects.requireNonNull(lock, "lock");
lock.lock();
return new AutoCloseableLock(lock);
}

private final Lock lock;

public AutoCloseableLock(final Lock lock) {
this.lock = lock;
}

@Override
public void close() {
this.lock.unlock();
}

public void lock() {
this.lock.lock();
}
}

The pro is less code and less chance for errors, the con is that you create
a new AutoCloseableLock for lock/unlock sites.

Gary

On Thu, Jun 23, 2016 at 4:54 PM, Matt Sicker  wrote:

> Sounds like an opportunity for a small Commons or independent project.
> CloseableLock!
>
> On 23 June 2016 at 18:51, Greg Thomas  wrote:
>
>> I''m sure I read somewhere that it was a deliberate choice not to make
>> it, to stop people using the very common pattern of creating the object in
>> the try() - which isn't much use for a lock.
>>
>> Greg
>> --
>> Sent from my iPhone
>>
>> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>>
>> Good idea!
>> Maybe propose this for Java 9?
>> Looks very reasonable to me.
>>
>> Sent from my iPhone
>>
>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>>
>> I wonder if anyone knows why Lock is not AutoCloseable.
>>
>> This:
>>
>> public static boolean hasManager(final String name) {
>> LOCK.lock();
>> try {
>> return MAP.containsKey(name);
>> } finally {
>> LOCK.unlock();
>> }
>> }
>>
>>
>> Seems lame in comparison to:
>>
>> public static boolean hasManager(final String name) {
>> try (LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Which, due to syntax really would be:
>>
>> public static boolean hasManager(final String name) {
>> try (Object o = LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>>
>> Just wonderin'...
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-23 Thread Matt Sicker

Sounds like an opportunity for a small Commons or independent project.
CloseableLock!

On 23 June 2016 at 18:51, Greg Thomas  wrote:

> I''m sure I read somewhere that it was a deliberate choice not to make it,
> to stop people using the very common pattern of creating the object in the
> try() - which isn't much use for a lock.
>
> Greg
> --
> Sent from my iPhone
>
> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
>
> Good idea!
> Maybe propose this for Java 9?
> Looks very reasonable to me.
>
> Sent from my iPhone
>
> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>
> I wonder if anyone knows why Lock is not AutoCloseable.
>
> This:
>
> public static boolean hasManager(final String name) {
> LOCK.lock();
> try {
> return MAP.containsKey(name);
> } finally {
> LOCK.unlock();
> }
> }
>
>
> Seems lame in comparison to:
>
> public static boolean hasManager(final String name) {
> try (LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Which, due to syntax really would be:
>
> public static boolean hasManager(final String name) {
> try (Object o = LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
>
> Just wonderin'...
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
Matt Sicker

Re: Lock pattern

2016-06-23 Thread Greg Thomas

I''m sure I read somewhere that it was a deliberate choice not to make it, to 
stop people using the very common pattern of creating the object in the try() - 
which isn't much use for a lock. 

Greg
-- 
Sent from my iPhone

> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
> 
> Good idea! 
> Maybe propose this for Java 9?
> Looks very reasonable to me. 
> 
> Sent from my iPhone
> 
>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>> 
>> I wonder if anyone knows why Lock is not AutoCloseable.
>> 
>> This:
>> 
>> public static boolean hasManager(final String name) {
>> LOCK.lock();
>> try {
>> return MAP.containsKey(name);
>> } finally {
>> LOCK.unlock();
>> }
>> }
>> 
>> 
>> Seems lame in comparison to:
>> 
>> public static boolean hasManager(final String name) {
>> try (LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>> 
>> Which, due to syntax really would be:
>> 
>> public static boolean hasManager(final String name) {
>> try (Object o = LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>> 
>> Just wonderin'...
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

2016-06-23 Thread Remko Popma

Good idea! 
Maybe propose this for Java 9?
Looks very reasonable to me. 

Sent from my iPhone

> On 2016/06/24, at 8:32, Gary Gregory  wrote:
> 
> I wonder if anyone knows why Lock is not AutoCloseable.
> 
> This:
> 
> public static boolean hasManager(final String name) {
> LOCK.lock();
> try {
> return MAP.containsKey(name);
> } finally {
> LOCK.unlock();
> }
> }
> 
> 
> Seems lame in comparison to:
> 
> public static boolean hasManager(final String name) {
> try (LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
> 
> Which, due to syntax really would be:
> 
> public static boolean hasManager(final String name) {
> try (Object o = LOCK.lock()) {
> return MAP.containsKey(name);
> }
> }
> 
> Just wonderin'...
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Lock pattern

2016-06-23 Thread Gary Gregory

I wonder if anyone knows why Lock is not AutoCloseable.

This:

public static boolean hasManager(final String name) {
LOCK.lock();
try {
return MAP.containsKey(name);
} finally {
LOCK.unlock();
}
}


Seems lame in comparison to:

public static boolean hasManager(final String name) {
try (LOCK.lock()) {
return MAP.containsKey(name);
}
}

Which, due to syntax really would be:

public static boolean hasManager(final String name) {
try (Object o = LOCK.lock()) {
return MAP.containsKey(name);
}
}

Just wonderin'...

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Re: Lock pattern

Lock pattern

20 matches

Site Navigation

Mail list logo

Footer information