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 <boa...@gmail.com> wrote:
> FWIW, I'm still interested in this AutoCloseableLock idea.
>
> On 23 June 2016 at 22:25, Gary Gregory <garydgreg...@gmail.com> 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 <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
>>
>
>
>
> --
> 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
