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 <pbened...@apache.org> 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" <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>
>>
>
--
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
