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>
