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
