You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/07/21 21:18:09 UTC
Re: Lock pattern
On Fri, Jun 24, 2016 at 11:44 AM, Paul Benedict <pb...@apache.org>
wrote:
> That may be the one! Thanks for searching for it. I can't believe it's
> from three years ago! :-) Anyway, it goes on for some time and provides
> good arguments to consider from both sides.
>
The whole thing is a mismatch IMO. On the one hand we have a _language
feature_, the try-with-resources statement. On the other we have the
AutoCloseable/Closeable interfaces that seem to have a very narrow focus,
which works nicely for low level objects like streams and also for very
different higher-level abstractions like JDBC Connections and ResultSets.
It seems that Locks are usually also a lower-level gadget like a stream,
even lower than a stream in fact. I could of course implement a very heavy
and resource intensive Lock, so YMMV.
Gary
>
> Cheers,
> Paul
>
> On Fri, Jun 24, 2016 at 4:10 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas <gr...@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.
>>>
>>
>> Here?
>> http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html
>>
>> Gary
>>
>>
>>>
>>>
>>> Greg
>>> --
>>> Sent from my iPhone
>>>
>>> On 24 Jun 2016, at 00:45, Remko Popma <re...@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 <ga...@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
Re: Lock pattern
Posted by Ralph Goers <ra...@dslextreme.com>.
What is a mismatch?
Things that are all AutoCloseable all used to have an instance of the object created and then make sure it was closed during a finally call. Locks generally don’t work that way. They are typically created when they object they reside in is created and are destroyed when the object itself is destroyed. Trying to equate lock() with open() or create() and unlock() to close() is a mistake IMO.
Ralph
> On Jul 21, 2016, at 2:18 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Fri, Jun 24, 2016 at 11:44 AM, Paul Benedict <pbenedict@apache.org <ma...@apache.org>> wrote:
> That may be the one! Thanks for searching for it. I can't believe it's from three years ago! :-) Anyway, it goes on for some time and provides good arguments to consider from both sides.
>
> The whole thing is a mismatch IMO. On the one hand we have a _language feature_, the try-with-resources statement. On the other we have the AutoCloseable/Closeable interfaces that seem to have a very narrow focus, which works nicely for low level objects like streams and also for very different higher-level abstractions like JDBC Connections and ResultSets. It seems that Locks are usually also a lower-level gadget like a stream, even lower than a stream in fact. I could of course implement a very heavy and resource intensive Lock, so YMMV.
>
> Gary
>
>
> Cheers,
> Paul
>
> On Fri, Jun 24, 2016 at 4:10 AM, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
> On Thu, Jun 23, 2016 at 4:51 PM, Greg Thomas <greg.d.thomas@gmail.com <ma...@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.
>
> Here? http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html <http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003114.html>
>
> Gary
>
>
>
> Greg
> --
> Sent from my iPhone
>
> On 24 Jun 2016, at 00:45, Remko Popma <remko.popma@gmail.com <ma...@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 <garydgregory@gmail.com <ma...@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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
>>> Home: http://garygregory.com/ <http://garygregory.com/>
>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@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 <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>