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> >