Please: try-with-resouces Lock support!

[Howard Lovatt]

You have a similar problem in C++:

if ( x < y ) { ... }

and

if ( x < y > xy = 0 ) { ... }

Some C++ compilers resolve this ambiguity by checking if x is a type
or a variable. You could do the same with Java. However I am sure the
Java guys no all this and therefore I am guessing that it isn't easy
to do inside Javac. If Java didn't have separate name spaces for types
it wouldn't be a problem, unfortunately Java didn't learn from Scheme
:(

You could allow:

try ( variable ) { ... }

Provided that variable was final or effectively final. That might be a
nice compromise.

 -- Howard.

On 5 March 2011 05:51, Dr Heinz M. Kabutz <heinz at javaspecialists.eu> wrote:
> Thanks Reinier,
>
> I will write a follow-up to my newsletter to explain why this is not going
> to work.  Glad I put the disclaimer in there ;-)
>
> Regards
>
> Heinz
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun Java Champion
> IEEE Certified Software Development Professional
> http://www.javaspecialists.eu
> Tel: +30 69 72 850 460
> Skype: kabutz
>
>
> On 3/4/11 3:47 PM, Reinier Zwitserloot wrote:
>
> To summarize the log, you can't tell the difference between generics on the
> type of a variable declaration and the lesser than operator:
>
> try (x < y ? resourceA : resourceB) {}
>
> vs:
>
> try (x<y> z = resourceA) {}
>
>
> An LL(k) parser can't tell the difference until its too late. A packrat/rd
> parser could, but both javac and ecj are LL(k) parsers so changing this
> would require both to be rewritten from scratch.
>
> Re-introducing the ability to use just an expression here would require some
> sort of keyword or symbol that is unambiguous. This could work:
>
> try (= expression) {}
>
> but it breaks the principle of least surprise, in that without knowing a
> heck of a lot about the capabilities of LL(k) parsers, the need for the =
> sign is a mystery.
>
> I gather from this discussion as well as the reaction to the fine work by
> Heinz Kabutz that the primary use case for expressions in ARM statements is
> locks, and this use case is not good enough, even if it is actually fast
> enough at least on server mode VMs.
>
>  --Reinier Zwitserloot
>
>
>
> On Sat, Feb 26, 2011 at 4:19 AM, Howard Lovatt
> <howard.lovatt at gmail.com>wrote:
>
>
>
> I haven't checked the specification, but on the latest JDK from the
> Mercurial repository:
>
>  try ( l.autoLock() ) { ... }
>
> Is fine,
>
>  -- Howard.
>
> On 26 February 2011 13:18, David Holmes <David.Holmes at oracle.com> wrote:
>
>
> Howard,
>
> The t-w-r needs a resource declaration, so as per my example you'd still
> need to do:
>
> try ( Lock l2 = l.autolock()) { ... }
>
> Using defenders to retrofit AutoCloseable to Lock does make it simpler to
> implement.
>
> However there's still additional overhead here and I wouldn't vote for
>
>
> this.
>
>
> David
>
> Howard Lovatt said the following on 02/26/11 10:40:
>
>
> The use case:
>
> try ( new ReentrantLock() ) { ... }
>
> makes no sense, you *need* to share the lock. However if Lock were
> modified to use defender methods:
>
> interface Lock extends AutoCloseable {
>
>  ... // As before
>
>  Lock autoLock()  default Trait.autoLock;
>
>  // Similarly autoLockInterruptibly
>
>  void close() default Trait.close;
>
>  static final class Trait {
>    public Lock autoLock(final Lock self) {
>      self.lock();
>      return self;
>    }
>
>    // Similarly autoLockInterruptibly
>
>    public void close(final Lock self) {
>      self.unlock();
>    }
>  }
> }
>
> Then
>
> try (l.autoLock()) { ... }
>
> would work.
>
>  -- Howard.
>
> On 24 February 2011 11:42, David Holmes <David.Holmes at oracle.com>
>
>
> wrote:
>
>
> I suspect Joe will shut this down as being out of scope for coin-dev in
> its present state, but my 2c
>
> Gernot Neppert said the following on 02/24/11 03:31:
>
>
> this has been discussed here before, but somehow got lost:
> Wouldn't it be very handy having a class
> "java.util.concurrent.AutoLockable" that could be used as follows:
>
>
> No not really. The way try-with-resources has evolved really doesn't
> mesh with lock usage. As Neal already mentioned the overhead of
>
>
> creating
>
>
> the AutoLockable per lock operation is simply prohibitive. Even if you
> retrofitted Lock with AutoCloseable you would still need (given t-w-r
> synatx) to have a helper method to acquire the lock and return it so
>
>
> you
>
>
> can assign it to the local:
>
>  try ( Lock l = Lock.lockAndReturn(lock) ) {
>  ...
>  }
>
> This is just a round-hole vs square-peg situation, and trying to make
>
>
> it
>
>
> fit really doesn't add anything to clarity or useability in my view.
>
> I can imagine a more general (more specific?) t-w-r that might allow:
>
> try (lock) {
>   ...
> }
>
> but that would be for future debate.
>
> Cheers,
> David Holmes
>
>
>
> try(AutoLockable locked = AutoLockable.locked(lock))
> {
> // Do something in locked scope
> }
>
> It would look something like this:
>
> package java.util.concurrent.locks;
>
> public abstract class AutoLockable implements AutoCloseable {
>
>     public static AutoLockable locked(final Lock lock)
>     {
>         lock.lock();
>         return new AutoLockable() {
>
>             @Override
>             public void close() {
>                 lock.unlock();
>             }
>         };
>     }
>
>     public abstract void close();
> }
>
>
>
>
>
>
> --
>   -- Howard.
>
>
>
>
>



-- 
  -- Howard.