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" <boa...@gmail.com> 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 <garydgreg...@gmail.com> wrote:
>
>> On Thu, Jun 23, 2016 at 5:52 PM, Matt Sicker <boa...@gmail.com> 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 <garydgreg...@gmail.com> 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 <boa...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Sounds like an opportunity for a small Commons or independent
>>>>>>> project. CloseableLock!
>>>>>>>
>>>>>>> On 23 June 2016 at 18:51, Greg Thomas <greg.d.tho...@gmail.com>
>>>>>>> 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 <remko.po...@gmail.com>
>>>>>>>> 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 <garydgreg...@gmail.com>
>>>>>>>> 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
>>>>>>>> <http://www.manning.com/bauer3/>
>>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>>> Home: http://garygregory.com/
>>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>> <http://www.manning.com/bauer3/>
>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>>> 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
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> 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
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
>

Reply via email to