From mcnepp02 at googlemail.com  Tue Mar  1 01:13:28 2011
From: mcnepp02 at googlemail.com (Gernot Neppert)
Date: Tue, 1 Mar 2011 09:13:28 +0000
Subject: AutoLock
In-Reply-To: <4D6CA550.3020807@paradise.net.nz>
References: <4D6AA639.7070709@javaspecialists.eu>
	<AANLkTikYCG7AK4OV8hi6Hr+MOo-6uCSGT10AQuQWy+qc@mail.gmail.com>
	<4D6CA550.3020807@paradise.net.nz>
Message-ID: <AANLkTi=p-jXKvvxRU1pagR73LuV8JZ=2JSQKnVvJTVFO@mail.gmail.com>

You're doubtlessly right. I guess I just got carried away by the idea
of being the source of a plagiatarism for once... Since I usually
don't publish anything, chances are so rare of it happening ;-)




2011/3/1 Bruce Chapman <brucechapman at paradise.net.nz>:
>
> If two people read the same old version of the spec and try to apply it
> outside the square, it is highly likely they will choose Locks and solve
> it in this same wrong way. That's not plagiarism, it's what happens when
> there is a lack of novelty in both the problem and solution.
>
>
> Bruce
>


From joe.darcy at oracle.com  Tue Mar  1 13:12:37 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 01 Mar 2011 13:12:37 -0800
Subject: Documentation of Project Coin features as implemented in the JDK
	7 developer preview
Message-ID: <4D6D6145.40100@oracle.com>

Hello.

I've posted documentation of the semantics of the Project Coin features 
as implemented in the JDK 7 developer preview,  b130, at:
http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html

Before sending in comments or questions about a feature to coin-dev, 
please read the discussion section after a feature.  Many design 
considerations are discussed in those sections.  Additionally, some 
known bugs in the current implementation are noted in the text.  In 
particular, javac in the JDK 7 developer preview erroneously accepts 
diamond combined with non-generic classes and accepts some uses of 
diamond with anonymous inner classes. These bugs will be corrected in 
future builds.

Happy reading,

-Joe


From reinier at zwitserloot.com  Fri Mar  4 05:47:12 2011
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Fri, 4 Mar 2011 14:47:12 +0100
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
Message-ID: <AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>

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


From howard.lovatt at gmail.com  Fri Mar  4 13:06:22 2011
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Sat, 5 Mar 2011 08:06:22 +1100
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <4D71349B.4060100@javaspecialists.eu>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D71349B.4060100@javaspecialists.eu>
Message-ID: <AANLkTikG74ne0HVVOr5zs+CMWmFP17BP7Ai8_9dYgToe@mail.gmail.com>

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.


From brucechapman at paradise.net.nz  Fri Mar  4 13:14:09 2011
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Sat, 05 Mar 2011 10:14:09 +1300
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
Message-ID: <4D715621.8050800@paradise.net.nz>

On 5/03/2011 2:47 a.m., 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.
>
Yep, that's a good summary.
> 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

I wouldn't say the prime use case is locks. The prime use case is 
anywhere here you want to access the resource in a catch or finally, 
because the scope of the
resource declaration is only the block.


Hence

try(Resource r  = getResource()) {
     doSomething(r);
} catch (ResourceException e) {
     System.out.println(e + " from " + r); // r undefined here
}

is invalid, you need to hoist the variable r outside the t-w-r so that 
it is in scope in the catch

Resource r  = getResource();
try(Resource rDash = r) {
     doSomething(r);
} catch (ResourceException e) {
     System.out.println(e + " from " + r); // r visible
}

which would be nicer (hence what I consider the primary use case for 
expr) if we could just write

Resource r  = getResource();
try(r) { // not currently permitted
     doSomething(r);
} catch (ResourceException e) {
     System.out.println(e + " from " + r);
}

This last case is currently illegal, but allowing an identifier (as a 
very limited subset of expression) as well has not been ruled out by the 
expert group, and does not have the ll(k) problems that a general 
expression does.

Bruce


From scolebourne at joda.org  Sat Mar  5 11:08:36 2011
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sat, 5 Mar 2011 19:08:36 +0000
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <4D715621.8050800@paradise.net.nz>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
Message-ID: <AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>

On 4 March 2011 21:14, Bruce Chapman <brucechapman at paradise.net.nz> wrote:
> I wouldn't say the prime use case is locks. The prime use case is
> anywhere here you want to access the resource in a catch or finally,
> because the scope of the resource declaration is only the block.
>
> try(Resource r ?= getResource()) {
> ? ? doSomething(r);
> } catch (ResourceException e) {
> ? ? System.out.println(e + " from " + r); // r undefined here
> }
>
> is invalid, you need to hoist the variable r outside the t-w-r so that
> it is in scope in the catch

Good point. And a concern to me.

> Resource r ?= getResource();
> try(Resource rDash = r) {
> ? ? doSomething(r);
> } catch (ResourceException e) {
> ? ? System.out.println(e + " from " + r); // r visible
> }

Horrible.

> Resource r ?= getResource();
> try(r) { // not currently permitted
> ? ? doSomething(r);
> } catch (ResourceException e) {
> ? ? System.out.println(e + " from " + r);
> }

Still not great.

But there is a "hack" solution:

try(Resource r  = getResource()) {try {
    doSomething(r);
} catch (ResourceException e) {
    System.out.println(e + " from " + r); // r undefined here
}}

Not ideal.

The problem is that the basic syntax for twr rather abuses try-catch.
In one way, it makes sense for r to be available within the catch and
finally blocks of twr. Its just that given the rest of Java, no-one
would expect that.

Right now, I don't see an easy syntax change to allow exceptions to
easily reference the resource. And that is a key downside IMO.

I do wonder if we're going to see coding standards down the line
suggesting that twr and try-catch-finally shouldn't be mixed.

Stephen


From neal at gafter.com  Sat Mar  5 12:18:31 2011
From: neal at gafter.com (Neal Gafter)
Date: Sat, 5 Mar 2011 12:18:31 -0800
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
Message-ID: <AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>

In the try-with-resource language construct, exceptions thrown during the
construction of the resource are caught in the catch clauses.  Therefore,
making the resource in scope be within the catch clause would be providing
access to a variable that is not definitely assigned.  Since a variable that
is final (by the try-with-resources specification), not definitely assigned
(because the exception might have occurred during the resource expression),
and not definitely unassigned (because the exception might have occurred
during the try block), it cannot be used in any way.  There is therefore no
point in making the variable be in scope within the catch clause.

The correct thing to do is Stephen' suggestion:

On Sat, Mar 5, 2011 at 11:08 AM, Stephen Colebourne <scolebourne at joda.org>wrote:

> But there is a "hack" solution:
>
> try(Resource r  = getResource()) {try {
>     doSomething(r);
> } catch (ResourceException e) {
>    System.out.println(e + " from " + r); // r undefined here
> }}
>
> Not ideal.
>

This is the correct solution, and it is both ideal and not a hack.  I'm not
sure I agree with your spacing and placement of curly braces, but that is a
style issue.  The semantics of this code are different (than a catch on the
try-with-resources statement) because the catch clause here only catches
exceptions thrown from within the inner try block.  If you want to use the
resource variable, that is exactly what you need.

At worst, this exchange demonstrates that the try-with-resources
specification is piling too much complexity on the already overly complex
try statement.

Cheers,
Neal


From tronicek at fit.cvut.cz  Sun Mar  6 03:23:26 2011
From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=)
Date: Sun, 6 Mar 2011 12:23:26 +0100
Subject: Huston, we have a problem !
In-Reply-To: <4D5EA48F.8020806@oracle.com>
References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de>
	<4D5E8B45.4030709@oracle.com>
	<2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz>
	<4D5EA48F.8020806@oracle.com>
Message-ID: <cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>

My answer is here (I also post it on my blog at
http://tronicek.blogspot.com/2011/03/do-we-really-need-in-diamond-operator.html):

As you may know, one of new features of upcoming Java 7 will be the
diamond operator. Purpose of the diamond operator is to simplify
instantiation of generic classes. For example, instead of
List<Integer> p = new ArrayList<Integer>();

with the diamond operator we can write only
List<Integer> p = new ArrayList<>();

and let compiler infer the value of type argument. Nice simplification.
But do we really need to write <>? Isn't new ArrayList() enough? In this
article, I will describe the arguments of the <> proponents and explain
why I think that these arguments are not very strong. However, I also
describe arguments why we need <>.

In Java 1.4, we had raw types only:
List p = new ArrayList();

Java 5 introduced generics:
List<Integer> p = new ArrayList<Integer>();

Many types in Java API were generified and even though we can still use
generic types as raw types, there is no reason for this in Java 5 or
newer. When generics were introduced, raw types were allowed for backward
compatibility so that we could gradually and smoothly adopt generics. For
example, code in Java 1.4 can be combined with new generic code because
raw and generic types are allowed together. This is also expressed in the
JLS (4.8 Raw Types):

"The use of raw types is allowed only as a concession to compatibility of
legacy code. The use of raw types in code written after the introduction
of genericity into the Java programming language is strongly discouraged.
It is possible that future versions of the Java programming language will
disallow the use of raw types."

Now let's go back to the diamond operator and ask again: "Do we really
need <>?". The proponents of the <> syntax say that we need <> to preserve
backward compatibility. Let's look at an example from the coin-dev
conference:

class Foo<X> {
   Foo(X x) { }
   Foo<X> get(X x) { return this; }
}

class Test {
   void test() {
      Foo<?> f1 = new Foo(1).get(""); //ok - can pass String where Object
is expected
      Foo<?> f2 = new Foo<>(1).get(""); //fail - cannot pass String where
Integer is expected
   }
}

This shows the difference between new Foo(1) and new Foo<>(1). Clearly,
these two are different and if we changed the semantics of new Foo(1), it
would break backward compatibility. But wait. Backward compatibility with
what? Isn't line
Foo<?> f1 = new Foo(1).get("");

a little suspicious? It uses generic type in the left part and raw type in
the right part. Although it is legal, it is probably either omission or
malpractice. And its legality is probably only a side effect of "a
concession to compatibility of legacy code".

Let's go further and look at another example from the coin-dev conference.
It shows the difference between raw type and parameterized type with the
diamond:

public class X<T> {
   public X(T t) { }
   public T get() { return null; }

   public static int f(String s) { return 1; }
   public static int f(Object o) { return 2; }

   public static void main(String[] args) {
      System.out.println(f(new X<>("").get()));
      System.out.println(f(new X("").get()));
   }
}

Let's play with the code a bit. Let's assume that there was a library with
the X class:

public class X {
   public X(Object o) { }
   public Object get() { return null; }
}

and some code that compiled against this library:

public class Client {
   static int f(String s) { return 1; }
   static int f(Object o) { return 2; }

   public static void main(String[] args) {
      System.out.println(f(new X("").get()));
   }
}

Then, the library was generified:

public class X<T> {
   public X(T t) { }
   public T get() { return null; }
}

and we compiled the client project against the generified version. Now, if
we changed the semantics of new X("") to new X<String>("") (or new X<>("")
with the diamond syntax), the code would behave differently. So, the
answer to the title question is 'yes'. If we want to stay backward
compatible, we need <> and we cannot put new X("") semantically equal to
new X<>("").

Another questions are how long can Java evolve and remain compatible with
concessions to compatibility and whether newcomers to Java will appreciate
this.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Maurizio Cimadamore napsal(a):
> On 18/02/11 15:46, "Zden?k Tron??ek" wrote:
>> Maurizio, this is not good example because the first call is not correct
>> here. So, if it does not compile it should not be wrong even if it
>> compiled under previous version.
> What is wrong about the following code?
>
> Foo f1 = new Foo(1).get("");
>
>
> Maurizio
>> And hopefully you do not want to drive the language design by a
>> requirement to be source compatible with sources which are apparently
>> wrong.
>>
>> Z.
>
>



From Ulf.Zibis at gmx.de  Sun Mar  6 11:41:59 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 06 Mar 2011 20:41:59 +0100
Subject: Huston, we have a problem !
In-Reply-To: <cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
References: <4D5BA123.8050801@univ-mlv.fr>
	<827hcxpfjh.fsf@mid.bfk.de>	<4D5E8B45.4030709@oracle.com>	<2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz>	<4D5EA48F.8020806@oracle.com>
	<cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
Message-ID: <4D73E387.4050104@gmx.de>

Am 06.03.2011 12:23, schrieb "Zden?k Tron??ek":
> class Foo<X>  {
>     Foo(X x) { }
>     Foo<X>  get(X x) { return this; }
> }
>
> class Test {
>     void test() {
>        Foo<?>  f1 = new Foo(1).get(""); //ok - can pass String where Object
> is expected
>        Foo<?>  f2 = new Foo<>(1).get(""); //fail - cannot pass String where
> Integer is expected
>     }
> }
>
> This shows the difference between new Foo(1) and new Foo<>(1). Clearly,
> these two are different and if we changed the semantics of new Foo(1), it
> would break backward compatibility. But wait. Backward compatibility with
> what? Isn't line
> Foo<?>  f1 = new Foo(1).get("");
>
> a little suspicious? It uses generic type in the left part and raw type in
> the right part. Although it is legal, it is probably either omission or
> malpractice. And its legality is probably only a side effect of "a
> concession to compatibility of legacy code".
I agree!

> public class X {
>     public X(Object o) { }
>     public Object get() { return null; }
> }
>
> and some code that compiled against this library:
>
> public class Client {
>     static int f(String s) { return 1; }
>     static int f(Object o) { return 2; }
>
>     public static void main(String[] args) {
>        System.out.println(f(new X("").get()));
>     }
> }
>
> Then, the library was generified:
>
> public class X<T>  {
>     public X(T t) { }
>     public T get() { return null; }
> }
>
> and we compiled the client project against the generified version. Now, if
> we changed the semantics of new X("") to new X<String>("") (or new X<>("")
> with the diamond syntax), the code would behave differently. So, the
> answer to the title question is 'yes'. If we want to stay backward
> compatible, we need<>  and we cannot put new X("") semantically equal to
> new X<>("").

You are right, but we could use in place of new X<>(""):
     (X<String>)new X("")
or:
     (String)new X("").get()

As the only purpose of the "diamond syntax" here is to determine one from the overloaded methods, 
IMHO the "cast syntax" would be much more descriptive, even for long experienced programmers, and 
avoid misinterpretation, confusion and too-much-too-learn-before-first-success at least for beginners.

We anyway *don't have any other choice* in case of:
     X x = new X("");
     System.out.println(f((String)x.get()));

... or if we have more than 2 overloaded f(...) methods !!!


So again, I don't understand, why we need the diamond operator. I think, we only need to allow 
without warning:
     Foo<?> f1 = new Foo(1).get("");
and:
     Foo<String> f1 = new Foo(1).get("");


-Ulf



From howard.lovatt at gmail.com  Sun Mar  6 15:36:36 2011
From: howard.lovatt at gmail.com (Howard Lovatt)
Date: Mon, 7 Mar 2011 10:36:36 +1100
Subject: Huston, we have a problem !
In-Reply-To: <cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de>
	<4D5E8B45.4030709@oracle.com>
	<2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz>
	<4D5EA48F.8020806@oracle.com>
	<cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
Message-ID: <AANLkTimma2mCV3kd0+UXKJa3crg_ZPzKZ1E3pAjFPJH5@mail.gmail.com>

Much as I agree with everything you said, this is old ground that was
gone over before and rejected by Oracle (then Sun). All the same
points have been made in the past, but yes it is frustrating that good
arguments haven't won the day. In summary, not worth bringing up again
until coin 8.

 -- Howard.

2011/3/6 "Zden?k Tron??ek" <tronicek at fit.cvut.cz>:
> My answer is here (I also post it on my blog at
> http://tronicek.blogspot.com/2011/03/do-we-really-need-in-diamond-operator.html):
>
> As you may know, one of new features of upcoming Java 7 will be the
> diamond operator. Purpose of the diamond operator is to simplify
> instantiation of generic classes. For example, instead of
> List<Integer> p = new ArrayList<Integer>();
>
> with the diamond operator we can write only
> List<Integer> p = new ArrayList<>();
>
> and let compiler infer the value of type argument. Nice simplification.
> But do we really need to write <>? Isn't new ArrayList() enough? In this
> article, I will describe the arguments of the <> proponents and explain
> why I think that these arguments are not very strong. However, I also
> describe arguments why we need <>.
>
> In Java 1.4, we had raw types only:
> List p = new ArrayList();
>
> Java 5 introduced generics:
> List<Integer> p = new ArrayList<Integer>();
>
> Many types in Java API were generified and even though we can still use
> generic types as raw types, there is no reason for this in Java 5 or
> newer. When generics were introduced, raw types were allowed for backward
> compatibility so that we could gradually and smoothly adopt generics. For
> example, code in Java 1.4 can be combined with new generic code because
> raw and generic types are allowed together. This is also expressed in the
> JLS (4.8 Raw Types):
>
> "The use of raw types is allowed only as a concession to compatibility of
> legacy code. The use of raw types in code written after the introduction
> of genericity into the Java programming language is strongly discouraged.
> It is possible that future versions of the Java programming language will
> disallow the use of raw types."
>
> Now let's go back to the diamond operator and ask again: "Do we really
> need <>?". The proponents of the <> syntax say that we need <> to preserve
> backward compatibility. Let's look at an example from the coin-dev
> conference:
>
> class Foo<X> {
> ? Foo(X x) { }
> ? Foo<X> get(X x) { return this; }
> }
>
> class Test {
> ? void test() {
> ? ? ?Foo<?> f1 = new Foo(1).get(""); //ok - can pass String where Object
> is expected
> ? ? ?Foo<?> f2 = new Foo<>(1).get(""); //fail - cannot pass String where
> Integer is expected
> ? }
> }
>
> This shows the difference between new Foo(1) and new Foo<>(1). Clearly,
> these two are different and if we changed the semantics of new Foo(1), it
> would break backward compatibility. But wait. Backward compatibility with
> what? Isn't line
> Foo<?> f1 = new Foo(1).get("");
>
> a little suspicious? It uses generic type in the left part and raw type in
> the right part. Although it is legal, it is probably either omission or
> malpractice. And its legality is probably only a side effect of "a
> concession to compatibility of legacy code".
>
> Let's go further and look at another example from the coin-dev conference.
> It shows the difference between raw type and parameterized type with the
> diamond:
>
> public class X<T> {
> ? public X(T t) { }
> ? public T get() { return null; }
>
> ? public static int f(String s) { return 1; }
> ? public static int f(Object o) { return 2; }
>
> ? public static void main(String[] args) {
> ? ? ?System.out.println(f(new X<>("").get()));
> ? ? ?System.out.println(f(new X("").get()));
> ? }
> }
>
> Let's play with the code a bit. Let's assume that there was a library with
> the X class:
>
> public class X {
> ? public X(Object o) { }
> ? public Object get() { return null; }
> }
>
> and some code that compiled against this library:
>
> public class Client {
> ? static int f(String s) { return 1; }
> ? static int f(Object o) { return 2; }
>
> ? public static void main(String[] args) {
> ? ? ?System.out.println(f(new X("").get()));
> ? }
> }
>
> Then, the library was generified:
>
> public class X<T> {
> ? public X(T t) { }
> ? public T get() { return null; }
> }
>
> and we compiled the client project against the generified version. Now, if
> we changed the semantics of new X("") to new X<String>("") (or new X<>("")
> with the diamond syntax), the code would behave differently. So, the
> answer to the title question is 'yes'. If we want to stay backward
> compatible, we need <> and we cannot put new X("") semantically equal to
> new X<>("").
>
> Another questions are how long can Java evolve and remain compatible with
> concessions to compatibility and whether newcomers to Java will appreciate
> this.
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Maurizio Cimadamore napsal(a):
>> On 18/02/11 15:46, "Zden?k Tron??ek" wrote:
>>> Maurizio, this is not good example because the first call is not correct
>>> here. So, if it does not compile it should not be wrong even if it
>>> compiled under previous version.
>> What is wrong about the following code?
>>
>> Foo f1 = new Foo(1).get("");
>>
>>
>> Maurizio
>>> And hopefully you do not want to drive the language design by a
>>> requirement to be source compatible with sources which are apparently
>>> wrong.
>>>
>>> Z.
>>
>>
>
>
>



-- 
? -- Howard.


From joe.darcy at oracle.com  Sun Mar  6 15:52:26 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 06 Mar 2011 15:52:26 -0800
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTikG74ne0HVVOr5zs+CMWmFP17BP7Ai8_9dYgToe@mail.gmail.com>
References: <4D4FEF3E.4080600@fh-landshut.de>
	<4D4FF65E.10605@univ-mlv.fr>	<4D4FFCE9.7090709@fh-landshut.de>
	<4D500271.8020005@univ-mlv.fr>	<4D500A70.2060802@fh-landshut.de>
	<4D500C4D.1020503@univ-mlv.fr>	<4D640767.4070208@fh-landshut.de>
	<4D640AA6.7010407@oracle.com>	<4D654489.3030300@googlemail.com>
	<4D65A969.5000307@oracle.com>	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>	<4D6862F5.6090606@oracle.com>	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>	<4D71349B.4060100@javaspecialists.eu>
	<AANLkTikG74ne0HVVOr5zs+CMWmFP17BP7Ai8_9dYgToe@mail.gmail.com>
Message-ID: <4D741E3A.6020902@oracle.com>

Howard Lovatt wrote:
> 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.
>
>   

Yes, the changelog of the JSR 334 specification compared to its EDR has 
contained the following sentences for a while:

> One potential future extension is to allow a resource to be specified 
> as an expression that is a final or effectively final variable. Such a 
> restricted expression form would remove the need to declare a resource 
> variable for the sole purpose of aliasing an existing variable while 
> avoiding pathologies stemming from the resource variable being 
> modified within the body of the |try|-with-resources statement. 

While this change is too late for JDK 7, it would be a fine refinement 
to consider for JDK 8.

-Joe


From joe.darcy at oracle.com  Sun Mar  6 16:00:02 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 06 Mar 2011 16:00:02 -0800
Subject: Huston, we have a problem !
In-Reply-To: <cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
References: <4D5BA123.8050801@univ-mlv.fr>
	<827hcxpfjh.fsf@mid.bfk.de>	<4D5E8B45.4030709@oracle.com>	<2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz>	<4D5EA48F.8020806@oracle.com>
	<cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
Message-ID: <4D742002.5090202@oracle.com>

Greetings.

This vein of feedback is at least 18 months late:
http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002173.html

I am not going to engage in a debate over whether or not diamond should 
be in JDK 7.

-Joe

Zden?k Tron??ek wrote:
> My answer is here (I also post it on my blog at
> http://tronicek.blogspot.com/2011/03/do-we-really-need-in-diamond-operator.html):
>
> As you may know, one of new features of upcoming Java 7 will be the
> diamond operator. Purpose of the diamond operator is to simplify
> instantiation of generic classes. For example, instead of
> List<Integer> p = new ArrayList<Integer>();
>
> with the diamond operator we can write only
> List<Integer> p = new ArrayList<>();
>
> and let compiler infer the value of type argument. Nice simplification.
> But do we really need to write <>? Isn't new ArrayList() enough? In this
> article, I will describe the arguments of the <> proponents and explain
> why I think that these arguments are not very strong. However, I also
> describe arguments why we need <>.
>
> In Java 1.4, we had raw types only:
> List p = new ArrayList();
>
> Java 5 introduced generics:
> List<Integer> p = new ArrayList<Integer>();
>
> Many types in Java API were generified and even though we can still use
> generic types as raw types, there is no reason for this in Java 5 or
> newer. When generics were introduced, raw types were allowed for backward
> compatibility so that we could gradually and smoothly adopt generics. For
> example, code in Java 1.4 can be combined with new generic code because
> raw and generic types are allowed together. This is also expressed in the
> JLS (4.8 Raw Types):
>
> "The use of raw types is allowed only as a concession to compatibility of
> legacy code. The use of raw types in code written after the introduction
> of genericity into the Java programming language is strongly discouraged.
> It is possible that future versions of the Java programming language will
> disallow the use of raw types."
>
> Now let's go back to the diamond operator and ask again: "Do we really
> need <>?". The proponents of the <> syntax say that we need <> to preserve
> backward compatibility. Let's look at an example from the coin-dev
> conference:
>
> class Foo<X> {
>    Foo(X x) { }
>    Foo<X> get(X x) { return this; }
> }
>
> class Test {
>    void test() {
>       Foo<?> f1 = new Foo(1).get(""); //ok - can pass String where Object
> is expected
>       Foo<?> f2 = new Foo<>(1).get(""); //fail - cannot pass String where
> Integer is expected
>    }
> }
>
> This shows the difference between new Foo(1) and new Foo<>(1). Clearly,
> these two are different and if we changed the semantics of new Foo(1), it
> would break backward compatibility. But wait. Backward compatibility with
> what? Isn't line
> Foo<?> f1 = new Foo(1).get("");
>
> a little suspicious? It uses generic type in the left part and raw type in
> the right part. Although it is legal, it is probably either omission or
> malpractice. And its legality is probably only a side effect of "a
> concession to compatibility of legacy code".
>
> Let's go further and look at another example from the coin-dev conference.
> It shows the difference between raw type and parameterized type with the
> diamond:
>
> public class X<T> {
>    public X(T t) { }
>    public T get() { return null; }
>
>    public static int f(String s) { return 1; }
>    public static int f(Object o) { return 2; }
>
>    public static void main(String[] args) {
>       System.out.println(f(new X<>("").get()));
>       System.out.println(f(new X("").get()));
>    }
> }
>
> Let's play with the code a bit. Let's assume that there was a library with
> the X class:
>
> public class X {
>    public X(Object o) { }
>    public Object get() { return null; }
> }
>
> and some code that compiled against this library:
>
> public class Client {
>    static int f(String s) { return 1; }
>    static int f(Object o) { return 2; }
>
>    public static void main(String[] args) {
>       System.out.println(f(new X("").get()));
>    }
> }
>
> Then, the library was generified:
>
> public class X<T> {
>    public X(T t) { }
>    public T get() { return null; }
> }
>
> and we compiled the client project against the generified version. Now, if
> we changed the semantics of new X("") to new X<String>("") (or new X<>("")
> with the diamond syntax), the code would behave differently. So, the
> answer to the title question is 'yes'. If we want to stay backward
> compatible, we need <> and we cannot put new X("") semantically equal to
> new X<>("").
>
> Another questions are how long can Java evolve and remain compatible with
> concessions to compatibility and whether newcomers to Java will appreciate
> this.
>
> Z.
>   



From neal at gafter.com  Sun Mar  6 17:36:27 2011
From: neal at gafter.com (Neal Gafter)
Date: Sun, 6 Mar 2011 17:36:27 -0800
Subject: Huston, we have a problem !
In-Reply-To: <AANLkTimma2mCV3kd0+UXKJa3crg_ZPzKZ1E3pAjFPJH5@mail.gmail.com>
References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de>
	<4D5E8B45.4030709@oracle.com>
	<2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz>
	<4D5EA48F.8020806@oracle.com>
	<cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
	<AANLkTimma2mCV3kd0+UXKJa3crg_ZPzKZ1E3pAjFPJH5@mail.gmail.com>
Message-ID: <AANLkTikK6YjxrFKBAug5NY8JAx=D6qM22TySc6A+oJOc@mail.gmail.com>

2011/3/6 Howard Lovatt <howard.lovatt at gmail.com>

> Much as I agree with everything you said, this is old ground that was
> gone over before and rejected by Oracle (then Sun). All the same
> points have been made in the past, but yes it is frustrating that good
> arguments haven't won the day. In summary, not worth bringing up again
> until coin 8.
>

Howard: I don't think have have understood Zden?k's argument.  To quote:


> 2011/3/6 "Zden?k Tron??ek" <tronicek at fit.cvut.cz>:
> > My answer is here (I also post it on my blog at
> >
> http://tronicek.blogspot.com/2011/03/do-we-really-need-in-diamond-operator.html
> ):
> >
> > ... Now, if
> > we changed the semantics of new X("") to new X<String>("") (or new
> X<>("")
> > with the diamond syntax), the code would behave differently. So, the
> > answer to the title question is 'yes'. If we want to stay backward
> > compatible, we need <> and we cannot put new X("") semantically equal to
> > new X<>("").
>

In short,  Zden?k's good argument did in fact win the day.


From tronicek at fit.cvut.cz  Sun Mar  6 21:41:51 2011
From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=)
Date: Mon, 7 Mar 2011 06:41:51 +0100
Subject: Huston, we have a problem !
In-Reply-To: <4D742002.5090202@oracle.com>
References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de>
	<4D5E8B45.4030709@oracle.com>
	<2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz>
	<4D5EA48F.8020806@oracle.com>
	<cc6b9d03fabbbe2fda8020d895f010cb.squirrel@imap.fit.cvut.cz>
	<4D742002.5090202@oracle.com>
Message-ID: <436763ae7920035365ac8d71017d6c5c.squirrel@imap.fit.cvut.cz>

Hi,

my post is a feedback to the explanation why we need the <> syntax. I do
not express any doubts whether the diamond operator should be in JDK 7 or
not and nor I have them.
And this kind of feedback is not late, I suppose.

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague


Joe Darcy napsal(a):
> Greetings.
>
> This vein of feedback is at least 18 months late:
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002173.html
>
> I am not going to engage in a debate over whether or not diamond should
> be in JDK 7.
>
> -Joe
>
> Zden?k Tron??ek wrote:
>> My answer is here (I also post it on my blog at
>> http://tronicek.blogspot.com/2011/03/do-we-really-need-in-diamond-operator.html):
>>
>> As you may know, one of new features of upcoming Java 7 will be the
>> diamond operator. Purpose of the diamond operator is to simplify
>> instantiation of generic classes. For example, instead of
>> List<Integer> p = new ArrayList<Integer>();
>>
>> with the diamond operator we can write only
>> List<Integer> p = new ArrayList<>();
>>
>> and let compiler infer the value of type argument. Nice simplification.
>> But do we really need to write <>? Isn't new ArrayList() enough? In this
>> article, I will describe the arguments of the <> proponents and explain
>> why I think that these arguments are not very strong. However, I also
>> describe arguments why we need <>.
>>
>> In Java 1.4, we had raw types only:
>> List p = new ArrayList();
>>
>> Java 5 introduced generics:
>> List<Integer> p = new ArrayList<Integer>();
>>
>> Many types in Java API were generified and even though we can still use
>> generic types as raw types, there is no reason for this in Java 5 or
>> newer. When generics were introduced, raw types were allowed for
>> backward
>> compatibility so that we could gradually and smoothly adopt generics.
>> For
>> example, code in Java 1.4 can be combined with new generic code because
>> raw and generic types are allowed together. This is also expressed in
>> the
>> JLS (4.8 Raw Types):
>>
>> "The use of raw types is allowed only as a concession to compatibility
>> of
>> legacy code. The use of raw types in code written after the introduction
>> of genericity into the Java programming language is strongly
>> discouraged.
>> It is possible that future versions of the Java programming language
>> will
>> disallow the use of raw types."
>>
>> Now let's go back to the diamond operator and ask again: "Do we really
>> need <>?". The proponents of the <> syntax say that we need <> to
>> preserve
>> backward compatibility. Let's look at an example from the coin-dev
>> conference:
>>
>> class Foo<X> {
>>    Foo(X x) { }
>>    Foo<X> get(X x) { return this; }
>> }
>>
>> class Test {
>>    void test() {
>>       Foo<?> f1 = new Foo(1).get(""); //ok - can pass String where
>> Object
>> is expected
>>       Foo<?> f2 = new Foo<>(1).get(""); //fail - cannot pass String
>> where
>> Integer is expected
>>    }
>> }
>>
>> This shows the difference between new Foo(1) and new Foo<>(1). Clearly,
>> these two are different and if we changed the semantics of new Foo(1),
>> it
>> would break backward compatibility. But wait. Backward compatibility
>> with
>> what? Isn't line
>> Foo<?> f1 = new Foo(1).get("");
>>
>> a little suspicious? It uses generic type in the left part and raw type
>> in
>> the right part. Although it is legal, it is probably either omission or
>> malpractice. And its legality is probably only a side effect of "a
>> concession to compatibility of legacy code".
>>
>> Let's go further and look at another example from the coin-dev
>> conference.
>> It shows the difference between raw type and parameterized type with the
>> diamond:
>>
>> public class X<T> {
>>    public X(T t) { }
>>    public T get() { return null; }
>>
>>    public static int f(String s) { return 1; }
>>    public static int f(Object o) { return 2; }
>>
>>    public static void main(String[] args) {
>>       System.out.println(f(new X<>("").get()));
>>       System.out.println(f(new X("").get()));
>>    }
>> }
>>
>> Let's play with the code a bit. Let's assume that there was a library
>> with
>> the X class:
>>
>> public class X {
>>    public X(Object o) { }
>>    public Object get() { return null; }
>> }
>>
>> and some code that compiled against this library:
>>
>> public class Client {
>>    static int f(String s) { return 1; }
>>    static int f(Object o) { return 2; }
>>
>>    public static void main(String[] args) {
>>       System.out.println(f(new X("").get()));
>>    }
>> }
>>
>> Then, the library was generified:
>>
>> public class X<T> {
>>    public X(T t) { }
>>    public T get() { return null; }
>> }
>>
>> and we compiled the client project against the generified version. Now,
>> if
>> we changed the semantics of new X("") to new X<String>("") (or new
>> X<>("")
>> with the diamond syntax), the code would behave differently. So, the
>> answer to the title question is 'yes'. If we want to stay backward
>> compatible, we need <> and we cannot put new X("") semantically equal to
>> new X<>("").
>>
>> Another questions are how long can Java evolve and remain compatible
>> with
>> concessions to compatibility and whether newcomers to Java will
>> appreciate
>> this.
>>
>> Z.
>>
>
>



From joe.darcy at oracle.com  Tue Mar  8 22:40:07 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 08 Mar 2011 22:40:07 -0800
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D6D6145.40100@oracle.com>
References: <4D6D6145.40100@oracle.com>
Message-ID: <4D7720C7.40102@oracle.com>

Joe Darcy wrote:
> Hello.
>
> I've posted documentation of the semantics of the Project Coin 
> features as implemented in the JDK 7 developer preview,  b130, at:
> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html 
>
>
> Before sending in comments or questions about a feature to coin-dev, 
> please read the discussion section after a feature.  Many design 
> considerations are discussed in those sections.  Additionally, some 
> known bugs in the current implementation are noted in the text.  In 
> particular, javac in the JDK 7 developer preview erroneously accepts 
> diamond combined with non-generic classes and accepts some uses of 
> diamond with anonymous inner classes. These bugs will be corrected in 
> future builds.
>
> Happy reading,
>
> -Joe

No comments from the coin-dev readership on the posted documentation?

-Joe


From Ulf.Zibis at gmx.de  Wed Mar  9 04:57:46 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 09 Mar 2011 13:57:46 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D7720C7.40102@oracle.com>
References: <4D6D6145.40100@oracle.com> <4D7720C7.40102@oracle.com>
Message-ID: <4D77794A.70009@gmx.de>

Why do you allow whitespace between the "<" and ">" of a diamond.

Is whitespace allowed for ++ operator e.g.?

-Ulf


Am 09.03.2011 07:40, schrieb Joe Darcy:
> Joe Darcy wrote:
>> Hello.
>>
>> I've posted documentation of the semantics of the Project Coin
>> features as implemented in the JDK 7 developer preview,  b130, at:
>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>
>>
>> Before sending in comments or questions about a feature to coin-dev,
>> please read the discussion section after a feature.  Many design
>> considerations are discussed in those sections.  Additionally, some
>> known bugs in the current implementation are noted in the text.  In
>> particular, javac in the JDK 7 developer preview erroneously accepts
>> diamond combined with non-generic classes and accepts some uses of
>> diamond with anonymous inner classes. These bugs will be corrected in
>> future builds.
>>
>> Happy reading,
>>
>> -Joe
> No comments from the coin-dev readership on the posted documentation?
>
> -Joe
>
>


From maurizio.cimadamore at oracle.com  Wed Mar  9 05:25:48 2011
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 09 Mar 2011 13:25:48 +0000
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D77794A.70009@gmx.de>
References: <4D6D6145.40100@oracle.com> <4D7720C7.40102@oracle.com>
	<4D77794A.70009@gmx.de>
Message-ID: <4D777FDC.3020206@oracle.com>

On 09/03/11 12:57, Ulf Zibis wrote:
> Why do you allow whitespace between the "<" and">" of a diamond.
Good catch - I don't think this is a spec problem, as the grammar for 
diamond is defined as follows in the latest draft:

/TypeArgumentsOrDiamond:/

        /TypeArguments/  

        |<||>|  


So it is more a compiler bug erroneously accepting spaces 'inside' the 
diamond. The compiler should be fixed.

Maurizio
> Is whitespace allowed for ++ operator e.g.?
>
> -Ulf
>
>
> Am 09.03.2011 07:40, schrieb Joe Darcy:
>> Joe Darcy wrote:
>>> Hello.
>>>
>>> I've posted documentation of the semantics of the Project Coin
>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>
>>>
>>> Before sending in comments or questions about a feature to coin-dev,
>>> please read the discussion section after a feature.  Many design
>>> considerations are discussed in those sections.  Additionally, some
>>> known bugs in the current implementation are noted in the text.  In
>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>> diamond combined with non-generic classes and accepts some uses of
>>> diamond with anonymous inner classes. These bugs will be corrected in
>>> future builds.
>>>
>>> Happy reading,
>>>
>>> -Joe
>> No comments from the coin-dev readership on the posted documentation?
>>
>> -Joe
>>
>>



From maurizio.cimadamore at oracle.com  Wed Mar  9 06:17:47 2011
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 09 Mar 2011 14:17:47 +0000
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D778578.5010704@oracle.com>
References: <4D6D6145.40100@oracle.com>
	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>
	<4D777FDC.3020206@oracle.com> <4D778578.5010704@oracle.com>
Message-ID: <4D778C0B.8020404@oracle.com>

On 09/03/11 13:49, Eamonn McManus wrote:
>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>> diamond. The compiler should be fixed.
> I don't understand this. We're not introducing a new lexical <> token, 
> are we? So obviously the compiler must allow spaces between < and >, 
> as between any pair of tokens. Stylistically, some people might prefer 
> to write List < Integer >, say, and would certainly be surprised not 
> to be able to write List < >.
I think it would be better if the compiler would be stricter about this, 
and to deal with diamond as if it were a token - otherwise, programmer 
might abuse of current behavior:

new ArrayList< >();

new ArrayList<
 >();

Which is ugly.

Maurizio
> ?amonn
>
> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>> On 09/03/11 12:57, Ulf Zibis wrote:
>>> Why do you allow whitespace between the "<" and">" of a diamond.
>> Good catch - I don't think this is a spec problem, as the grammar for
>> diamond is defined as follows in the latest draft:
>>
>> /TypeArgumentsOrDiamond:/
>>
>>          /TypeArguments/
>>
>>          |<||>|
>>
>>
>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>> diamond. The compiler should be fixed.
>>
>> Maurizio
>>> Is whitespace allowed for ++ operator e.g.?
>>>
>>> -Ulf
>>>
>>>
>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>> Joe Darcy wrote:
>>>>> Hello.
>>>>>
>>>>> I've posted documentation of the semantics of the Project Coin
>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>
>>>>>
>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>> please read the discussion section after a feature.  Many design
>>>>> considerations are discussed in those sections.  Additionally, some
>>>>> known bugs in the current implementation are noted in the text.  In
>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>> future builds.
>>>>>
>>>>> Happy reading,
>>>>>
>>>>> -Joe
>>>> No comments from the coin-dev readership on the posted documentation?
>>>>
>>>> -Joe
>>>>
>>>>



From forax at univ-mlv.fr  Wed Mar  9 06:30:31 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 09 Mar 2011 15:30:31 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D778C0B.8020404@oracle.com>
References: <4D6D6145.40100@oracle.com>	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>	<4D777FDC.3020206@oracle.com>
	<4D778578.5010704@oracle.com> <4D778C0B.8020404@oracle.com>
Message-ID: <4D778F07.9020700@univ-mlv.fr>

On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
> On 09/03/11 13:49, Eamonn McManus wrote:
>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>> diamond. The compiler should be fixed.
>> I don't understand this. We're not introducing a new lexical<>  token,
>> are we? So obviously the compiler must allow spaces between<  and>,
>> as between any pair of tokens. Stylistically, some people might prefer
>> to write List<  Integer>, say, and would certainly be surprised not
>> to be able to write List<  >.
> I think it would be better if the compiler would be stricter about this,
> and to deal with diamond as if it were a token - otherwise, programmer
> might abuse of current behavior:
>
> new ArrayList<  >();
>
> new ArrayList<
>   >();
>
> Which is ugly.
>
> Maurizio

It's not fundamentally different from
new ArrayList
<>
();
which is legal.

And considering <> is a kind of new operator is weird.

As ?amonn says new ArrayList < String > is legal so new ArrayList < > 
should be legal.

R?mi

>> ?amonn
>>
>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>> Good catch - I don't think this is a spec problem, as the grammar for
>>> diamond is defined as follows in the latest draft:
>>>
>>> /TypeArgumentsOrDiamond:/
>>>
>>>           /TypeArguments/
>>>
>>>           |<||>|
>>>
>>>
>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>> diamond. The compiler should be fixed.
>>>
>>> Maurizio
>>>> Is whitespace allowed for ++ operator e.g.?
>>>>
>>>> -Ulf
>>>>
>>>>
>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>> Joe Darcy wrote:
>>>>>> Hello.
>>>>>>
>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>
>>>>>>
>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>> please read the discussion section after a feature.  Many design
>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>> future builds.
>>>>>>
>>>>>> Happy reading,
>>>>>>
>>>>>> -Joe
>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>
>>>>> -Joe
>>>>>
>>>>>
>



From maurizio.cimadamore at oracle.com  Wed Mar  9 06:39:20 2011
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 09 Mar 2011 14:39:20 +0000
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D77903C.3010707@oracle.com>
References: <4D6D6145.40100@oracle.com>
	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>
	<4D777FDC.3020206@oracle.com> <4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D77903C.3010707@oracle.com>
Message-ID: <4D779118.9010908@oracle.com>

On 09/03/11 14:35, Eamonn McManus wrote:
>> I think it would be better if the compiler would be stricter about 
>> this, and to deal with diamond as if it were a token - otherwise, 
>> programmer might abuse of current behavior:
> I don't think the compiler can deal with diamond "as if it were a token". 
Read: we introduce a '<>' token (which I think was clear form the context)
> Either it's a token or it's not. So, either we introduce a <> token 
> (which I personally think would be a bad idea) or the compiler has to 
> accept < >. It's not supposed to be in the business of telling you 
> whether your code is nicely formatted.
I think there are valid arguments both ways.

Maurizio
> ?amonn
>
> On 9/3/11 3:17 PM, Maurizio Cimadamore wrote:
>> On 09/03/11 13:49, Eamonn McManus wrote:
>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>> diamond. The compiler should be fixed.
>>> I don't understand this. We're not introducing a new lexical <> 
>>> token, are we? So obviously the compiler must allow spaces between < 
>>> and >, as between any pair of tokens. Stylistically, some people 
>>> might prefer to write List < Integer >, say, and would certainly be 
>>> surprised not to be able to write List < >.
>> I think it would be better if the compiler would be stricter about 
>> this, and to deal with diamond as if it were a token - otherwise, 
>> programmer might abuse of current behavior:
>>
>> new ArrayList< >();
>>
>> new ArrayList<
>> >();
>>
>> Which is ugly.
>>
>> Maurizio
>>> ?amonn
>>>
>>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>> Good catch - I don't think this is a spec problem, as the grammar for
>>>> diamond is defined as follows in the latest draft:
>>>>
>>>> /TypeArgumentsOrDiamond:/
>>>>
>>>>          /TypeArguments/
>>>>
>>>>          |<||>|
>>>>
>>>>
>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>> diamond. The compiler should be fixed.
>>>>
>>>> Maurizio
>>>>> Is whitespace allowed for ++ operator e.g.?
>>>>>
>>>>> -Ulf
>>>>>
>>>>>
>>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>>> Joe Darcy wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>>
>>>>>>>
>>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>>> please read the discussion section after a feature.  Many design
>>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>>> future builds.
>>>>>>>
>>>>>>> Happy reading,
>>>>>>>
>>>>>>> -Joe
>>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>
>>



From jesper.oqvist at cs.lth.se  Wed Mar  9 06:47:38 2011
From: jesper.oqvist at cs.lth.se (=?ISO-8859-1?Q?Jesper_=D6qvist?=)
Date: Wed, 09 Mar 2011 15:47:38 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D778F07.9020700@univ-mlv.fr>
References: <4D6D6145.40100@oracle.com>	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>	<4D777FDC.3020206@oracle.com>	<4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D778F07.9020700@univ-mlv.fr>
Message-ID: <4D77930A.6010204@cs.lth.se>

R?mi Forax wrote:
> On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
>   
>> On 09/03/11 13:49, Eamonn McManus wrote:
>>     
>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>> diamond. The compiler should be fixed.
>>>>         
>>> I don't understand this. We're not introducing a new lexical<>  token,
>>> are we? So obviously the compiler must allow spaces between<  and>,
>>> as between any pair of tokens. Stylistically, some people might prefer
>>> to write List<  Integer>, say, and would certainly be surprised not
>>> to be able to write List<  >.
>>>       
>> I think it would be better if the compiler would be stricter about this,
>> and to deal with diamond as if it were a token - otherwise, programmer
>> might abuse of current behavior:
>>
>> new ArrayList<  >();
>>
>> new ArrayList<
>>   >();
>>
>> Which is ugly.
>>
>> Maurizio
>>     
>
> It's not fundamentally different from
> new ArrayList
> <>
> ();
> which is legal.
>
> And considering <> is a kind of new operator is weird.
>   
Exactly! A type parameter list is similar to a method argument list, and 
it is allowed to have whitespace between the parenthesis of a parameter 
list.

I don't see why you should be able to write

new ArrayList<>(
);

and not

new ArrayList<
 >();

even though I agree that the last example is a bit unsightly.

/Jesper
> As ?amonn says new ArrayList < String > is legal so new ArrayList < > 
> should be legal.
>
> R?mi
>
>   
>>> ?amonn
>>>
>>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>>       
>>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>>         
>>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>>>           
>>>> Good catch - I don't think this is a spec problem, as the grammar for
>>>> diamond is defined as follows in the latest draft:
>>>>
>>>> /TypeArgumentsOrDiamond:/
>>>>
>>>>           /TypeArguments/
>>>>
>>>>           |<||>|
>>>>
>>>>
>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>> diamond. The compiler should be fixed.
>>>>
>>>> Maurizio
>>>>         
>>>>> Is whitespace allowed for ++ operator e.g.?
>>>>>
>>>>> -Ulf
>>>>>
>>>>>
>>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>>           
>>>>>> Joe Darcy wrote:
>>>>>>             
>>>>>>> Hello.
>>>>>>>
>>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>>
>>>>>>>
>>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>>> please read the discussion section after a feature.  Many design
>>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>>> future builds.
>>>>>>>
>>>>>>> Happy reading,
>>>>>>>
>>>>>>> -Joe
>>>>>>>               
>>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>
>>>>>>             
>
>
>   



From eamonn.mcmanus at oracle.com  Wed Mar  9 06:52:30 2011
From: eamonn.mcmanus at oracle.com (Eamonn McManus)
Date: Wed, 09 Mar 2011 15:52:30 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D779118.9010908@oracle.com>
References: <4D6D6145.40100@oracle.com>
	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>
	<4D777FDC.3020206@oracle.com> <4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D77903C.3010707@oracle.com>
	<4D779118.9010908@oracle.com>
Message-ID: <4D77942E.1050306@oracle.com>

 > Read: we introduce a '<>' token (which I think was clear form the 
context)

OK. It wasn't all that clear to me, since the grammar quoted in an 
earlier message is syntactic, not lexical, and there are no changes to 
the lexical grammar. So in fact it *is* a spec problem if we think <> 
should be a token.

I still think it would be surprising to allow spaces in List < String > 
but not in List<>, especially since the existing grammar goes out of its 
way to allow both List<List<String>> and List<List<String> >. But if we 
think the <> token might mean something else the future (a mutant 
Pascalish not-equal operator, say) then that might be an argument for it.

?amonn

On 9/3/11 3:39 PM, Maurizio Cimadamore wrote:
> On 09/03/11 14:35, Eamonn McManus wrote:
>>> I think it would be better if the compiler would be stricter about
>>> this, and to deal with diamond as if it were a token - otherwise,
>>> programmer might abuse of current behavior:
>> I don't think the compiler can deal with diamond "as if it were a token".
> Read: we introduce a '<>' token (which I think was clear form the context)
>> Either it's a token or it's not. So, either we introduce a <> token
>> (which I personally think would be a bad idea) or the compiler has to
>> accept < >. It's not supposed to be in the business of telling you
>> whether your code is nicely formatted.
> I think there are valid arguments both ways.
>
> Maurizio
>> ?amonn
>>
>> On 9/3/11 3:17 PM, Maurizio Cimadamore wrote:
>>> On 09/03/11 13:49, Eamonn McManus wrote:
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>>> diamond. The compiler should be fixed.
>>>> I don't understand this. We're not introducing a new lexical <>
>>>> token, are we? So obviously the compiler must allow spaces between <
>>>> and >, as between any pair of tokens. Stylistically, some people
>>>> might prefer to write List < Integer >, say, and would certainly be
>>>> surprised not to be able to write List < >.
>>> I think it would be better if the compiler would be stricter about
>>> this, and to deal with diamond as if it were a token - otherwise,
>>> programmer might abuse of current behavior:
>>>
>>> new ArrayList< >();
>>>
>>> new ArrayList<
>>> >();
>>>
>>> Which is ugly.
>>>
>>> Maurizio
>>>> ?amonn
>>>>
>>>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>>> Good catch - I don't think this is a spec problem, as the grammar for
>>>>> diamond is defined as follows in the latest draft:
>>>>>
>>>>> /TypeArgumentsOrDiamond:/
>>>>>
>>>>>          /TypeArguments/
>>>>>
>>>>>          |<||>|
>>>>>
>>>>>
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>>> diamond. The compiler should be fixed.
>>>>>
>>>>> Maurizio
>>>>>> Is whitespace allowed for ++ operator e.g.?
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>>
>>>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>>>> Joe Darcy wrote:
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>>>
>>>>>>>>
>>>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>>>> please read the discussion section after a feature.  Many design
>>>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>>>> future builds.
>>>>>>>>
>>>>>>>> Happy reading,
>>>>>>>>
>>>>>>>> -Joe
>>>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>>
>>>
>


From maurizio.cimadamore at oracle.com  Wed Mar  9 07:00:19 2011
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 09 Mar 2011 15:00:19 +0000
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D778F07.9020700@univ-mlv.fr>
References: <4D6D6145.40100@oracle.com>	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>	<4D777FDC.3020206@oracle.com>	<4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D778F07.9020700@univ-mlv.fr>
Message-ID: <4D779603.5000402@oracle.com>

On 09/03/11 14:30, R?mi Forax wrote:
> On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
>> On 09/03/11 13:49, Eamonn McManus wrote:
>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>> diamond. The compiler should be fixed.
>>> I don't understand this. We're not introducing a new lexical<>   token,
>>> are we? So obviously the compiler must allow spaces between<   and>,
>>> as between any pair of tokens. Stylistically, some people might prefer
>>> to write List<   Integer>, say, and would certainly be surprised not
>>> to be able to write List<   >.
>> I think it would be better if the compiler would be stricter about this,
>> and to deal with diamond as if it were a token - otherwise, programmer
>> might abuse of current behavior:
>>
>> new ArrayList<   >();
>>
>> new ArrayList<
>>    >();
>>
>> Which is ugly.
>>
>> Maurizio
> It's not fundamentally different from
> new ArrayList
> <>
> ();
> which is legal.
I see, so since the above is allowed, let's add a further level:

new ArrayList
<
>
();

:-)
> And considering<>  is a kind of new operator is weird.
>
I haven't used the 'operator' word once in my earlier emails.
> As ?amonn says new ArrayList<  String>  is legal so new ArrayList<  >
> should be legal.
As I said, I think that this argument can go both ways: one can think 
that diamond is special enough to deserve special treatement; on the 
other hand, one would like diamond to be uniform with standard type 
argument lists. In my opinion, the benefits of treating '<>' as a single 
token outweights the problems (at the end of the day, the only arguably 
sensible thing that you couldn't do is 'Foo< >' - note the space).

Said that, all this is speculation - as Ulf pointed out, the spec is 
explicitly allowing whitespaces inside diamonds (strange thing is that 
doesn't seem to allow other separators... but I think that needs to 
follow if '<' and '>' are separate tokens).

Maurizio
> R?mi
>
>>> ?amonn
>>>
>>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>> Good catch - I don't think this is a spec problem, as the grammar for
>>>> diamond is defined as follows in the latest draft:
>>>>
>>>> /TypeArgumentsOrDiamond:/
>>>>
>>>>            /TypeArguments/
>>>>
>>>>            |<||>|
>>>>
>>>>
>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>> diamond. The compiler should be fixed.
>>>>
>>>> Maurizio
>>>>> Is whitespace allowed for ++ operator e.g.?
>>>>>
>>>>> -Ulf
>>>>>
>>>>>
>>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>>> Joe Darcy wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>>
>>>>>>>
>>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>>> please read the discussion section after a feature.  Many design
>>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>>> future builds.
>>>>>>>
>>>>>>> Happy reading,
>>>>>>>
>>>>>>> -Joe
>>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>
>



From forax at univ-mlv.fr  Wed Mar  9 07:02:44 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 09 Mar 2011 16:02:44 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D77942E.1050306@oracle.com>
References: <4D6D6145.40100@oracle.com>	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>	<4D777FDC.3020206@oracle.com>
	<4D778578.5010704@oracle.com>	<4D778C0B.8020404@oracle.com>
	<4D77903C.3010707@oracle.com>	<4D779118.9010908@oracle.com>
	<4D77942E.1050306@oracle.com>
Message-ID: <4D779694.7030100@univ-mlv.fr>

On 03/09/2011 03:52 PM, Eamonn McManus wrote:
>   >  Read: we introduce a '<>' token (which I think was clear form the
> context)
>
> OK. It wasn't all that clear to me, since the grammar quoted in an
> earlier message is syntactic, not lexical, and there are no changes to
> the lexical grammar. So in fact it *is* a spec problem if we think<>
> should be a token.
>
> I still think it would be surprising to allow spaces in List<  String>
> but not in List<>, especially since the existing grammar goes out of its
> way to allow both List<List<String>>  and List<List<String>  >. But if we
> think the<>  token might mean something else the future (a mutant
> Pascalish not-equal operator, say) then that might be an argument for it.
>
> ?amonn

Argh, the crystal ball argument "Perhaps in the future, we will ..."
counter argument: but by saying that you change the future so it's 
perhaps no true anymore :)

R?mi



From forax at univ-mlv.fr  Wed Mar  9 07:08:33 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 09 Mar 2011 16:08:33 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D779603.5000402@oracle.com>
References: <4D6D6145.40100@oracle.com>	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>	<4D777FDC.3020206@oracle.com>	<4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D778F07.9020700@univ-mlv.fr>
	<4D779603.5000402@oracle.com>
Message-ID: <4D7797F1.8030300@univ-mlv.fr>

On 03/09/2011 04:00 PM, Maurizio Cimadamore wrote:
> On 09/03/11 14:30, R?mi Forax wrote:
>> On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
>>> On 09/03/11 13:49, Eamonn McManus wrote:
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' 
>>>>> the
>>>>> diamond. The compiler should be fixed.
>>>> I don't understand this. We're not introducing a new lexical<>   
>>>> token,
>>>> are we? So obviously the compiler must allow spaces between<   and>,
>>>> as between any pair of tokens. Stylistically, some people might prefer
>>>> to write List<   Integer>, say, and would certainly be surprised not
>>>> to be able to write List< >.
>>> I think it would be better if the compiler would be stricter about 
>>> this,
>>> and to deal with diamond as if it were a token - otherwise, programmer
>>> might abuse of current behavior:
>>>
>>> new ArrayList< >();
>>>
>>> new ArrayList<
>>> >();
>>>
>>> Which is ugly.
>>>
>>> Maurizio
>> It's not fundamentally different from
>> new ArrayList
>> <>
>> ();
>> which is legal.
> I see, so since the above is allowed, let's add a further level:
>
> new ArrayList
> <
>>
> ();
>
> :-)
>> And considering<>  is a kind of new operator is weird.
>>
> I haven't used the 'operator' word once in my earlier emails.

Yes, but we both know how the scanner of javac will name it :)

>> As ?amonn says new ArrayList<  String>  is legal so new ArrayList< >
>> should be legal.
> As I said, I think that this argument can go both ways: one can think 
> that diamond is special enough to deserve special treatement; on the 
> other hand, one would like diamond to be uniform with standard type 
> argument lists. In my opinion, the benefits of treating '<>' as a 
> single token outweights the problems (at the end of the day, the only 
> arguably sensible thing that you couldn't do is 'Foo< >' - note the 
> space).
>
> Said that, all this is speculation - as Ulf pointed out, the spec is 
> explicitly allowing whitespaces inside diamonds (strange thing is that 
> doesn't seem to allow other separators... but I think that needs to 
> follow if '<' and '>' are separate tokens).
>
> Maurizio
>> R?mi

R?mi



From reinier at zwitserloot.com  Wed Mar  9 07:15:41 2011
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Wed, 9 Mar 2011 16:15:41 +0100
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
Message-ID: <AANLkTi=uOHmmapVcvzCTTTzP7Lsk4+XN-JMEbO94HECo@mail.gmail.com>

This snippet:

try (Resource r = getResource()) {
   .....
} catch (SomeException e) {
   ... do something with r....
}


implies that getResource() is not expected to fail. This is quite different
from for example an inputstream:

try (InputStream r = new FileInputStream(file)) { ... }

where an exception on the constructor call is expected and the current
specified behaviour of ARM matches this expectation (notably: that it
includes the initializing expression as part of the 'try').

There are a few solutions when the expectation is for the expression not to
fail as in the getResource example:

(1) Do *NOT* consider the expression as part of the 'try'. Short of
introducing some new keyword to specify which behaviour you want, Stephen's
example of try (Resource r = ...) { try { ..... }} does exactly that, and is
the only way to do this.

(2) Allow both with the same try statement. However, as in practice any
expression can theoretically fail with any exception, the solution would
have to be that 'r' is set to null if the initializing expression does not
complete normally. The syntax sugar to make this work isn't trivial but it
can be done.

One could then write:

try (Resource r = getResource()) {
   ....
} catch (Exception e) {
    icon = Icons.DEFAULT_ICON;
    logger.log("App icon resource " + r.getURL() + " is not available", e);
}

and if the exception that triggered the catch block to run occurred in the
evaluation of "getResource()", the above code would produce an NPE on the
log line. Better than a core dump, I guess. As with any null resource, such
a resource will not be closed, and no exception is caused by the fact that
'r' is null when its time to clean it up. (which would be following the
execution of the catch block).

Whether doing this is a good idea is something I leave to the readers, but
it is another consistent alternative and does look slightly cleaner, though
there's far more magic going on with this version.


 --Reinier Zwitserloot



On Sat, Mar 5, 2011 at 9:18 PM, Neal Gafter <neal at gafter.com> wrote:

> In the try-with-resource language construct, exceptions thrown during the
> construction of the resource are caught in the catch clauses.  Therefore,
> making the resource in scope be within the catch clause would be providing
> access to a variable that is not definitely assigned.  Since a variable
> that
> is final (by the try-with-resources specification), not definitely assigned
> (because the exception might have occurred during the resource expression),
> and not definitely unassigned (because the exception might have occurred
> during the try block), it cannot be used in any way.  There is therefore no
> point in making the variable be in scope within the catch clause.
>
> The correct thing to do is Stephen' suggestion:
>
> On Sat, Mar 5, 2011 at 11:08 AM, Stephen Colebourne <scolebourne at joda.org
> >wrote:
>
> > But there is a "hack" solution:
> >
> > try(Resource r  = getResource()) {try {
> >     doSomething(r);
> > } catch (ResourceException e) {
> >    System.out.println(e + " from " + r); // r undefined here
> > }}
> >
> > Not ideal.
> >
>
> This is the correct solution, and it is both ideal and not a hack.  I'm not
> sure I agree with your spacing and placement of curly braces, but that is a
> style issue.  The semantics of this code are different (than a catch on the
> try-with-resources statement) because the catch clause here only catches
> exceptions thrown from within the inner try block.  If you want to use the
> resource variable, that is exactly what you need.
>
> At worst, this exchange demonstrates that the try-with-resources
> specification is piling too much complexity on the already overly complex
> try statement.
>
> Cheers,
> Neal
>
>


From markmahieu at gmail.com  Wed Mar  9 07:23:11 2011
From: markmahieu at gmail.com (Mark Mahieu)
Date: Wed, 9 Mar 2011 15:23:11 +0000
Subject: Documentation of Project Coin features as implemented in the JDK
	7 developer preview
In-Reply-To: <4D779603.5000402@oracle.com>
References: <4D6D6145.40100@oracle.com>	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>	<4D777FDC.3020206@oracle.com>	<4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D778F07.9020700@univ-mlv.fr>
	<4D779603.5000402@oracle.com>
Message-ID: <1409A035-800C-4D3E-8099-54E8DF795A9A@gmail.com>

Somewhat perverse thought - would anyone want to write a comment in there, I wonder...

	List<Integer> percentages = new ArrayList</* 0-100 only, please! */>();


Mark


On 9 Mar 2011, at 15:00, Maurizio Cimadamore wrote:

> On 09/03/11 14:30, R?mi Forax wrote:
>> On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
>>> On 09/03/11 13:49, Eamonn McManus wrote:
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>>> diamond. The compiler should be fixed.
>>>> I don't understand this. We're not introducing a new lexical<>   token,
>>>> are we? So obviously the compiler must allow spaces between<   and>,
>>>> as between any pair of tokens. Stylistically, some people might prefer
>>>> to write List<   Integer>, say, and would certainly be surprised not
>>>> to be able to write List<   >.
>>> I think it would be better if the compiler would be stricter about this,
>>> and to deal with diamond as if it were a token - otherwise, programmer
>>> might abuse of current behavior:
>>> 
>>> new ArrayList<   >();
>>> 
>>> new ArrayList<
>>>> ();
>>> 
>>> Which is ugly.
>>> 
>>> Maurizio
>> It's not fundamentally different from
>> new ArrayList
>> <>
>> ();
>> which is legal.
> I see, so since the above is allowed, let's add a further level:
> 
> new ArrayList
> <
>> 
> ();
> 
> :-)
>> And considering<>  is a kind of new operator is weird.
>> 
> I haven't used the 'operator' word once in my earlier emails.
>> As ?amonn says new ArrayList<  String>  is legal so new ArrayList<  >
>> should be legal.
> As I said, I think that this argument can go both ways: one can think 
> that diamond is special enough to deserve special treatement; on the 
> other hand, one would like diamond to be uniform with standard type 
> argument lists. In my opinion, the benefits of treating '<>' as a single 
> token outweights the problems (at the end of the day, the only arguably 
> sensible thing that you couldn't do is 'Foo< >' - note the space).
> 
> Said that, all this is speculation - as Ulf pointed out, the spec is 
> explicitly allowing whitespaces inside diamonds (strange thing is that 
> doesn't seem to allow other separators... but I think that needs to 
> follow if '<' and '>' are separate tokens).
> 
> Maurizio
>> R?mi
>> 
>>>> ?amonn
>>>> 
>>>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>>> Good catch - I don't think this is a spec problem, as the grammar for
>>>>> diamond is defined as follows in the latest draft:
>>>>> 
>>>>> /TypeArgumentsOrDiamond:/
>>>>> 
>>>>>           /TypeArguments/
>>>>> 
>>>>>           |<||>|
>>>>> 
>>>>> 
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>>> diamond. The compiler should be fixed.
>>>>> 
>>>>> Maurizio
>>>>>> Is whitespace allowed for ++ operator e.g.?
>>>>>> 
>>>>>> -Ulf
>>>>>> 
>>>>>> 
>>>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>>>> Joe Darcy wrote:
>>>>>>>> Hello.
>>>>>>>> 
>>>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>>>> please read the discussion section after a feature.  Many design
>>>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>>>> future builds.
>>>>>>>> 
>>>>>>>> Happy reading,
>>>>>>>> 
>>>>>>>> -Joe
>>>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>>> 
>>>>>>> -Joe
>>>>>>> 
>>>>>>> 
>> 
> 
> 



From reinier at zwitserloot.com  Wed Mar  9 07:26:53 2011
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Wed, 9 Mar 2011 16:26:53 +0100
Subject: Documentation of Project Coin features as implemented in the JDK
	7 developer preview
In-Reply-To: <4D779603.5000402@oracle.com>
References: <4D6D6145.40100@oracle.com> <4D7720C7.40102@oracle.com>
	<4D77794A.70009@gmx.de> <4D777FDC.3020206@oracle.com>
	<4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D778F07.9020700@univ-mlv.fr>
	<4D779603.5000402@oracle.com>
Message-ID: <AANLkTimMmVtEgGEdjNYzoN3K8_dB2bZJ5ODYY7=C74Hz@mail.gmail.com>

I thought the decision was made that only 1 underscore was allowed per set
of underscores in a number. i.e. legal:

0b1111_0000_1111_0_1_0;

not legal:

0b1111_____0000;

The spec as written allows any number of underscores.

I don't think it it matters much either way.

For consistency, < and > should remain separate tokens which implies writing
new ArrayList<>(); with funky spacing is perfectly legitimate. As has been
said, the compiler's job is not to enforce code style. Also, by leaving them
as separate tokens you can put comments inside which could be useful.

Introducing <> as a separate token in the future is not impossible if we
don't adopt <> as a singular token today; "new" "typename" "<>" will be
defined as an alternative syntax for the diamond operator, equal to "new"
"typename" "<" ">".

 --Reinier Zwitserloot



On Wed, Mar 9, 2011 at 4:00 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 09/03/11 14:30, R?mi Forax wrote:
> > On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
> >> On 09/03/11 13:49, Eamonn McManus wrote:
> >>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
> >>>> diamond. The compiler should be fixed.
> >>> I don't understand this. We're not introducing a new lexical<>   token,
> >>> are we? So obviously the compiler must allow spaces between<   and>,
> >>> as between any pair of tokens. Stylistically, some people might prefer
> >>> to write List<   Integer>, say, and would certainly be surprised not
> >>> to be able to write List<   >.
> >> I think it would be better if the compiler would be stricter about this,
> >> and to deal with diamond as if it were a token - otherwise, programmer
> >> might abuse of current behavior:
> >>
> >> new ArrayList<   >();
> >>
> >> new ArrayList<
> >>    >();
> >>
> >> Which is ugly.
> >>
> >> Maurizio
> > It's not fundamentally different from
> > new ArrayList
> > <>
> > ();
> > which is legal.
> I see, so since the above is allowed, let's add a further level:
>
> new ArrayList
> <
> >
> ();
>
> :-)
> > And considering<>  is a kind of new operator is weird.
> >
> I haven't used the 'operator' word once in my earlier emails.
> > As ?amonn says new ArrayList<  String>  is legal so new ArrayList<  >
> > should be legal.
> As I said, I think that this argument can go both ways: one can think
> that diamond is special enough to deserve special treatement; on the
> other hand, one would like diamond to be uniform with standard type
> argument lists. In my opinion, the benefits of treating '<>' as a single
> token outweights the problems (at the end of the day, the only arguably
> sensible thing that you couldn't do is 'Foo< >' - note the space).
>
> Said that, all this is speculation - as Ulf pointed out, the spec is
> explicitly allowing whitespaces inside diamonds (strange thing is that
> doesn't seem to allow other separators... but I think that needs to
> follow if '<' and '>' are separate tokens).
>
> Maurizio
> > R?mi
> >
> >>> ?amonn
> >>>
> >>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
> >>>> On 09/03/11 12:57, Ulf Zibis wrote:
> >>>>> Why do you allow whitespace between the "<" and">" of a diamond.
> >>>> Good catch - I don't think this is a spec problem, as the grammar for
> >>>> diamond is defined as follows in the latest draft:
> >>>>
> >>>> /TypeArgumentsOrDiamond:/
> >>>>
> >>>>            /TypeArguments/
> >>>>
> >>>>            |<||>|
> >>>>
> >>>>
> >>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
> >>>> diamond. The compiler should be fixed.
> >>>>
> >>>> Maurizio
> >>>>> Is whitespace allowed for ++ operator e.g.?
> >>>>>
> >>>>> -Ulf
> >>>>>
> >>>>>
> >>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
> >>>>>> Joe Darcy wrote:
> >>>>>>> Hello.
> >>>>>>>
> >>>>>>> I've posted documentation of the semantics of the Project Coin
> >>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
> >>>>>>>
> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
> >>>>>>>
> >>>>>>>
> >>>>>>> Before sending in comments or questions about a feature to
> coin-dev,
> >>>>>>> please read the discussion section after a feature.  Many design
> >>>>>>> considerations are discussed in those sections.  Additionally, some
> >>>>>>> known bugs in the current implementation are noted in the text.  In
> >>>>>>> particular, javac in the JDK 7 developer preview erroneously
> accepts
> >>>>>>> diamond combined with non-generic classes and accepts some uses of
> >>>>>>> diamond with anonymous inner classes. These bugs will be corrected
> in
> >>>>>>> future builds.
> >>>>>>>
> >>>>>>> Happy reading,
> >>>>>>>
> >>>>>>> -Joe
> >>>>>> No comments from the coin-dev readership on the posted
> documentation?
> >>>>>>
> >>>>>> -Joe
> >>>>>>
> >>>>>>
> >
>
>
>


From neal at gafter.com  Wed Mar  9 09:12:17 2011
From: neal at gafter.com (Neal Gafter)
Date: Wed, 9 Mar 2011 09:12:17 -0800
Subject: Documentation of Project Coin features as implemented in the JDK
	7 developer preview
In-Reply-To: <4D7797F1.8030300@univ-mlv.fr>
References: <4D6D6145.40100@oracle.com> <4D7720C7.40102@oracle.com>
	<4D77794A.70009@gmx.de> <4D777FDC.3020206@oracle.com>
	<4D778578.5010704@oracle.com>
	<4D778C0B.8020404@oracle.com> <4D778F07.9020700@univ-mlv.fr>
	<4D779603.5000402@oracle.com> <4D7797F1.8030300@univ-mlv.fr>
Message-ID: <AANLkTi=NK79nj5HsuSJTRsSV4kfDjHT6T_Gohj-v4Tff@mail.gmail.com>

On Wed, Mar 9, 2011 at 7:08 AM, R?mi Forax <forax at univ-mlv.fr> wrote:

> Yes, but we both know how the scanner of javac will name it :)
>

Don't be too sure.  <http://gafter.blogspot.com/2007/01/primate-parts.html>

Cheers,
Neal


From joe.darcy at oracle.com  Wed Mar  9 09:37:14 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 09 Mar 2011 09:37:14 -0800
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D777FDC.3020206@oracle.com>
References: <4D6D6145.40100@oracle.com>
	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>
	<4D777FDC.3020206@oracle.com>
Message-ID: <4D77BACA.7070201@oracle.com>

Hello.

As noted in subsequent discussion, the "diamond operator" isn't really 
an operator and we have taken to not referring to it as such.  For 
consistency, I think it is fine to allow (but discourage) extra white 
space between the "<" and ">" characters of a diamond.  I find this 
similar to the allowable white space between  the "@" and type name of 
an annotation.

Cheers,

-Joe

Maurizio Cimadamore wrote:
> On 09/03/11 12:57, Ulf Zibis wrote:
>   
>> Why do you allow whitespace between the "<" and">" of a diamond.
>>     
> Good catch - I don't think this is a spec problem, as the grammar for 
> diamond is defined as follows in the latest draft:
>
> /TypeArgumentsOrDiamond:/
>
>         /TypeArguments/  
>
>         |<||>|  
>
>
> So it is more a compiler bug erroneously accepting spaces 'inside' the 
> diamond. The compiler should be fixed.
>
> Maurizio
>   
>> Is whitespace allowed for ++ operator e.g.?
>>
>> -Ulf
>>
>>
>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>     
>>> Joe Darcy wrote:
>>>       
>>>> Hello.
>>>>
>>>> I've posted documentation of the semantics of the Project Coin
>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>
>>>>
>>>> Before sending in comments or questions about a feature to coin-dev,
>>>> please read the discussion section after a feature.  Many design
>>>> considerations are discussed in those sections.  Additionally, some
>>>> known bugs in the current implementation are noted in the text.  In
>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>> diamond combined with non-generic classes and accepts some uses of
>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>> future builds.
>>>>
>>>> Happy reading,
>>>>
>>>> -Joe
>>>>         
>>> No comments from the coin-dev readership on the posted documentation?
>>>
>>> -Joe
>>>
>>>
>>>       
>
>
>   



From scolebourne at joda.org  Wed Mar  9 10:20:16 2011
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 9 Mar 2011 18:20:16 +0000
Subject: Documentation of Project Coin features as implemented in the JDK
	7 developer preview
In-Reply-To: <4D77BACA.7070201@oracle.com>
References: <4D6D6145.40100@oracle.com> <4D7720C7.40102@oracle.com>
	<4D77794A.70009@gmx.de> <4D777FDC.3020206@oracle.com>
	<4D77BACA.7070201@oracle.com>
Message-ID: <AANLkTik8xTv2G267aDf=LTrwGHXVg3rROvHiC=RXS2mZ@mail.gmail.com>

I saw this in the original draft and meant to comment on it being odd.
Having read this discussion though, I agree with allowing '< >' with
space on the basis that its just a reduced '<Foo>'. So, anything a
regular '< X >' allows, should be allowed by diamond.

Stephen

On 9 March 2011 17:37, Joe Darcy <joe.darcy at oracle.com> wrote:
> Hello.
>
> As noted in subsequent discussion, the "diamond operator" isn't really
> an operator and we have taken to not referring to it as such. ?For
> consistency, I think it is fine to allow (but discourage) extra white
> space between the "<" and ">" characters of a diamond. ?I find this
> similar to the allowable white space between ?the "@" and type name of
> an annotation.
>
> Cheers,
>
> -Joe
>
> Maurizio Cimadamore wrote:
>> On 09/03/11 12:57, Ulf Zibis wrote:
>>
>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>
>> Good catch - I don't think this is a spec problem, as the grammar for
>> diamond is defined as follows in the latest draft:
>>
>> /TypeArgumentsOrDiamond:/
>>
>> ? ? ? ? /TypeArguments/
>>
>> ? ? ? ? |<||>|
>>
>>
>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>> diamond. The compiler should be fixed.
>>
>> Maurizio
>>
>>> Is whitespace allowed for ++ operator e.g.?
>>>
>>> -Ulf
>>>
>>>
>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>
>>>> Joe Darcy wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I've posted documentation of the semantics of the Project Coin
>>>>> features as implemented in the JDK 7 developer preview, ?b130, at:
>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>
>>>>>
>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>> please read the discussion section after a feature. ?Many design
>>>>> considerations are discussed in those sections. ?Additionally, some
>>>>> known bugs in the current implementation are noted in the text. ?In
>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>> future builds.
>>>>>
>>>>> Happy reading,
>>>>>
>>>>> -Joe
>>>>>
>>>> No comments from the coin-dev readership on the posted documentation?
>>>>
>>>> -Joe
>>>>
>>>>
>>>>
>>
>>
>>
>
>
>


From Ulf.Zibis at gmx.de  Wed Mar  9 12:23:06 2011
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 09 Mar 2011 21:23:06 +0100
Subject: Documentation of Project Coin features as implemented in the
	JDK 7 developer preview
In-Reply-To: <4D77BACA.7070201@oracle.com>
References: <4D6D6145.40100@oracle.com>
	<4D7720C7.40102@oracle.com>	<4D77794A.70009@gmx.de>
	<4D777FDC.3020206@oracle.com> <4D77BACA.7070201@oracle.com>
Message-ID: <4D77E1AA.8000805@gmx.de>

Am 09.03.2011 18:37, schrieb Joe Darcy:
> Hello.
>
> As noted in subsequent discussion, the "diamond operator" isn't really an operator and we have 
> taken to not referring to it as such.  For consistency, I think it is fine to allow (but 
> discourage) extra white space between the "<" and ">" characters of a diamond.  I find this 
> similar to the allowable white space between  the "@" and type name of an annotation.
>
> Cheers,
>
> -Joe
>

Surprised about the lifely discussion (about the color of the bike shed). :-o

To be consequent, we should rename the construct to "empty type list" and forget all about diamond 
(operator).

Otherwise, what about "bubble" for "( )" ? ;-)

-Ulf



From brucechapman at paradise.net.nz  Wed Mar  9 13:17:18 2011
From: brucechapman at paradise.net.nz (brucechapman at paradise.net.nz)
Date: Thu, 10 Mar 2011 10:17:18 +1300 (NZDT)
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTi=uOHmmapVcvzCTTTzP7Lsk4+XN-JMEbO94HECo@mail.gmail.com>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
	<AANLkTi=uOHmmapVcvzCTTTzP7Lsk4+XN-JMEbO94HECo@mail.gmail.com>
Message-ID: <1299705438.4d77ee5edbf35@www.paradise.net.nz>

Quoting Reinier Zwitserloot <reinier at zwitserloot.com>:

> This snippet:
> 
> try (Resource r = getResource()) {
>  .....
> } catch (SomeException e) {
>  ... do something with r....
> }
> 
> 
> implies that getResource() is not expected to fail. This is quite
> different
> from for example an inputstream:

implies how?

Neal's post which you quote suggested to me the perspective that in t-w-r, any
catch or finally clause is really about the resource initialisation (and
closing), and NOT really (or at least not so much) about exceptions thrown in
the block. If you want to catch exceptions in the block, use the nested try
idiom suggested by Stephen's email and confirmed by Neal.  This is not obvious.
 But your statement 'implies that getResource() is not expected to fail.' is not
consistent with this perspective because you have a catch in the t-w-r, which
signifies that you are expecting getResource() to fail (assuming any expected
failure of close() doesn't need explicit handling).

If the perspective above is correct (I am not saying it is - I am suggesting it
might be), or at least leads to correct code, then maybe we should give a hint
of that in the JSR spec so we (and people who will write books about this stuff,
and people that will explain it to others) send people off in the right
direction to start with.

Then again, I may well be deluded.

Bruce

> 
> try (InputStream r = new FileInputStream(file)) { ... }
> 
> where an exception on the constructor call is expected and the current
> specified behaviour of ARM matches this expectation (notably: that it
> includes the initializing expression as part of the 'try').
> 
> There are a few solutions when the expectation is for the expression not
> to
> fail as in the getResource example:
> 
> (1) Do *NOT* consider the expression as part of the 'try'. Short of
> introducing some new keyword to specify which behaviour you want,
> Stephen's
> example of try (Resource r = ...) { try { ..... }} does exactly that,
> and is
> the only way to do this.
> 
> (2) Allow both with the same try statement. However, as in practice any
> expression can theoretically fail with any exception, the solution
> would
> have to be that 'r' is set to null if the initializing expression does
> not
> complete normally. The syntax sugar to make this work isn't trivial but
> it
> can be done.
> 
> One could then write:
> 
> try (Resource r = getResource()) {
>  ....
> } catch (Exception e) {
>  icon = Icons.DEFAULT_ICON;
>  logger.log("App icon resource " + r.getURL() + " is not available",
> e);
> }
> 
> and if the exception that triggered the catch block to run occurred in
> the
> evaluation of "getResource()", the above code would produce an NPE on
> the
> log line. Better than a core dump, I guess. As with any null resource,
> such
> a resource will not be closed, and no exception is caused by the fact
> that
> 'r' is null when its time to clean it up. (which would be following the
> execution of the catch block).
> 
> Whether doing this is a good idea is something I leave to the readers,
> but
> it is another consistent alternative and does look slightly cleaner,
> though
> there's far more magic going on with this version.
> 
> 
>  --Reinier Zwitserloot
> 
> 
> 
> On Sat, Mar 5, 2011 at 9:18 PM, Neal Gafter <neal at gafter.com> wrote:
> 
> > In the try-with-resource language construct, exceptions thrown during
> the
> > construction of the resource are caught in the catch clauses.
> Therefore,
> > making the resource in scope be within the catch clause would be
> providing
> > access to a variable that is not definitely assigned. Since a
> variable
> > that
> > is final (by the try-with-resources specification), not definitely
> assigned
> > (because the exception might have occurred during the resource
> expression),
> > and not definitely unassigned (because the exception might have
> occurred
> > during the try block), it cannot be used in any way. There is
> therefore no
> > point in making the variable be in scope within the catch clause.
> >
> > The correct thing to do is Stephen' suggestion:
> >
> > On Sat, Mar 5, 2011 at 11:08 AM, Stephen Colebourne
> <scolebourne at joda.org
> > >wrote:
> >
> > > But there is a "hack" solution:
> > >
> > > try(Resource r = getResource()) {try {
> > > doSomething(r);
> > > } catch (ResourceException e) {
> > > System.out.println(e + " from " + r); // r undefined here
> > > }}
> > >
> > > Not ideal.
> > >
> >
> > This is the correct solution, and it is both ideal and not a hack. I'm
> not
> > sure I agree with your spacing and placement of curly braces, but that
> is a
> > style issue. The semantics of this code are different (than a catch on
> the
> > try-with-resources statement) because the catch clause here only
> catches
> > exceptions thrown from within the inner try block. If you want to use
> the
> > resource variable, that is exactly what you need.
> >
> > At worst, this exchange demonstrates that the try-with-resources
> > specification is piling too much complexity on the already overly
> complex
> > try statement.
> >
> > Cheers,
> > Neal
> >
> >
> 
>  



From brucechapman at paradise.net.nz  Fri Mar 11 01:17:51 2011
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Fri, 11 Mar 2011 22:17:51 +1300
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <1299705438.4d77ee5edbf35@www.paradise.net.nz>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
	<AANLkTi=uOHmmapVcvzCTTTzP7Lsk4+XN-JMEbO94HECo@mail.gmail.com>
	<1299705438.4d77ee5edbf35@www.paradise.net.nz>
Message-ID: <4D79E8BF.2020105@paradise.net.nz>

On 10/03/2011 10:17 a.m., brucechapman at paradise.net.nz wrote:
> Quoting Reinier Zwitserloot<reinier at zwitserloot.com>:
>
>> This snippet:
>>
>> try (Resource r = getResource()) {
>>   .....
>> } catch (SomeException e) {
>>   ... do something with r....
>> }
>>
>>
>> implies that getResource() is not expected to fail. This is quite
>> different
>> from for example an inputstream:
> implies how?
>
> Neal's post which you quote suggested to me the perspective that in t-w-r, any
> catch or finally clause is really about the resource initialisation (and
> closing), and NOT really (or at least not so much) about exceptions thrown in
> the block. If you want to catch exceptions in the block, use the nested try
> idiom suggested by Stephen's email and confirmed by Neal.  This is not obvious.
>   But your statement 'implies that getResource() is not expected to fail.' is not
> consistent with this perspective because you have a catch in the t-w-r, which
> signifies that you are expecting getResource() to fail (assuming any expected
> failure of close() doesn't need explicit handling).
>
> If the perspective above is correct (I am not saying it is - I am suggesting it
> might be), or at least leads to correct code, then maybe we should give a hint
> of that in the JSR spec so we (and people who will write books about this stuff,
> and people that will explain it to others) send people off in the right
> direction to start with.
>
> Then again, I may well be deluded.

Hmm, 24hrs of silence, no-one has said I am not deluded, no one has said 
anything, I am raising the confidence level on the deluded option, and 
off for a weekend of canoeing (provided the "possible" tsunami doesn't 
ruin that) to reground myself.

Bruce

> Bruce
>
>> try (InputStream r = new FileInputStream(file)) { ... }
>>
>> where an exception on the constructor call is expected and the current
>> specified behaviour of ARM matches this expectation (notably: that it
>> includes the initializing expression as part of the 'try').
>>
>> There are a few solutions when the expectation is for the expression not
>> to
>> fail as in the getResource example:
>>
>> (1) Do *NOT* consider the expression as part of the 'try'. Short of
>> introducing some new keyword to specify which behaviour you want,
>> Stephen's
>> example of try (Resource r = ...) { try { ..... }} does exactly that,
>> and is
>> the only way to do this.
>>
>> (2) Allow both with the same try statement. However, as in practice any
>> expression can theoretically fail with any exception, the solution
>> would
>> have to be that 'r' is set to null if the initializing expression does
>> not
>> complete normally. The syntax sugar to make this work isn't trivial but
>> it
>> can be done.
>>
>> One could then write:
>>
>> try (Resource r = getResource()) {
>>   ....
>> } catch (Exception e) {
>>   icon = Icons.DEFAULT_ICON;
>>   logger.log("App icon resource " + r.getURL() + " is not available",
>> e);
>> }
>>
>> and if the exception that triggered the catch block to run occurred in
>> the
>> evaluation of "getResource()", the above code would produce an NPE on
>> the
>> log line. Better than a core dump, I guess. As with any null resource,
>> such
>> a resource will not be closed, and no exception is caused by the fact
>> that
>> 'r' is null when its time to clean it up. (which would be following the
>> execution of the catch block).
>>
>> Whether doing this is a good idea is something I leave to the readers,
>> but
>> it is another consistent alternative and does look slightly cleaner,
>> though
>> there's far more magic going on with this version.
>>
>>
>>   --Reinier Zwitserloot
>>
>>
>>
>> On Sat, Mar 5, 2011 at 9:18 PM, Neal Gafter<neal at gafter.com>  wrote:
>>
>>> In the try-with-resource language construct, exceptions thrown during
>> the
>>> construction of the resource are caught in the catch clauses.
>> Therefore,
>>> making the resource in scope be within the catch clause would be
>> providing
>>> access to a variable that is not definitely assigned. Since a
>> variable
>>> that
>>> is final (by the try-with-resources specification), not definitely
>> assigned
>>> (because the exception might have occurred during the resource
>> expression),
>>> and not definitely unassigned (because the exception might have
>> occurred
>>> during the try block), it cannot be used in any way. There is
>> therefore no
>>> point in making the variable be in scope within the catch clause.
>>>
>>> The correct thing to do is Stephen' suggestion:
>>>
>>> On Sat, Mar 5, 2011 at 11:08 AM, Stephen Colebourne
>> <scolebourne at joda.org
>>>> wrote:
>>>> But there is a "hack" solution:
>>>>
>>>> try(Resource r = getResource()) {try {
>>>> doSomething(r);
>>>> } catch (ResourceException e) {
>>>> System.out.println(e + " from " + r); // r undefined here
>>>> }}
>>>>
>>>> Not ideal.
>>>>
>>> This is the correct solution, and it is both ideal and not a hack. I'm
>> not
>>> sure I agree with your spacing and placement of curly braces, but that
>> is a
>>> style issue. The semantics of this code are different (than a catch on
>> the
>>> try-with-resources statement) because the catch clause here only
>> catches
>>> exceptions thrown from within the inner try block. If you want to use
>> the
>>> resource variable, that is exactly what you need.
>>>
>>> At worst, this exchange demonstrates that the try-with-resources
>>> specification is piling too much complexity on the already overly
>> complex
>>> try statement.
>>>
>>> Cheers,
>>> Neal
>>>
>>>
>>
>
>



From fweimer at bfk.de  Fri Mar 11 01:28:34 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Fri, 11 Mar 2011 09:28:34 +0000
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
	(Neal Gafter's message of "Sat\, 5 Mar 2011 12\:18\:31 -0800")
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
Message-ID: <82k4g60zwd.fsf@mid.bfk.de>

* Neal Gafter:

> At worst, this exchange demonstrates that the try-with-resources
> specification is piling too much complexity on the already overly complex
> try statement.

Agreed.  Would it make sense to remove catch and finally clauses from
the try-with-resource construct?

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From forax at univ-mlv.fr  Fri Mar 11 02:48:29 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 11 Mar 2011 11:48:29 +0100
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <82k4g60zwd.fsf@mid.bfk.de>
References: <4D4FEF3E.4080600@fh-landshut.de>
	<4D4FF65E.10605@univ-mlv.fr>	<4D4FFCE9.7090709@fh-landshut.de>
	<4D500271.8020005@univ-mlv.fr>	<4D500A70.2060802@fh-landshut.de>
	<4D500C4D.1020503@univ-mlv.fr>	<4D640767.4070208@fh-landshut.de>
	<4D640AA6.7010407@oracle.com>	<4D654489.3030300@googlemail.com>
	<4D65A969.5000307@oracle.com>	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>	<4D6862F5.6090606@oracle.com>	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>	<4D715621.8050800@paradise.net.nz>	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
	<82k4g60zwd.fsf@mid.bfk.de>
Message-ID: <4D79FDFD.4070707@univ-mlv.fr>

On 03/11/2011 10:28 AM, Florian Weimer wrote:
> * Neal Gafter:
>
>> At worst, this exchange demonstrates that the try-with-resources
>> specification is piling too much complexity on the already overly complex
>> try statement.
> Agreed.  Would it make sense to remove catch and finally clauses from
> the try-with-resource construct?
>

Good question.

R?mi



From serge.boulay at gmail.com  Fri Mar 11 05:07:00 2011
From: serge.boulay at gmail.com (Serge Boulay)
Date: Fri, 11 Mar 2011 08:07:00 -0500
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <4D79FDFD.4070707@univ-mlv.fr>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
	<82k4g60zwd.fsf@mid.bfk.de> <4D79FDFD.4070707@univ-mlv.fr>
Message-ID: <AANLkTimFiDinVy7igsdg7aoV5feVnTb8MueP57qw6qzZ@mail.gmail.com>

well, the original proposal did not use the "try" construct. Instead it used
the "do" statement.

do (someResource)
{

}



On Fri, Mar 11, 2011 at 5:48 AM, R?mi Forax <forax at univ-mlv.fr> wrote:

> On 03/11/2011 10:28 AM, Florian Weimer wrote:
> > * Neal Gafter:
> >
> >> At worst, this exchange demonstrates that the try-with-resources
> >> specification is piling too much complexity on the already overly
> complex
> >> try statement.
> > Agreed.  Would it make sense to remove catch and finally clauses from
> > the try-with-resource construct?
> >
>
> Good question.
>
> R?mi
>
>
>


From reinier at zwitserloot.com  Fri Mar 11 19:58:58 2011
From: reinier at zwitserloot.com (Reinier Zwitserloot)
Date: Sat, 12 Mar 2011 04:58:58 +0100
Subject: Please: try-with-resouces Lock support!
In-Reply-To: <1299705438.4d77ee5edbf35@www.paradise.net.nz>
References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr>
	<4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr>
	<4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr>
	<4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com>
	<4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com>
	<AANLkTik6_Z+wX6LftmVVhdtWS7YwfjHc9awuwu3UnbSG@mail.gmail.com>
	<4D6862F5.6090606@oracle.com>
	<AANLkTimFGyabmMLwk7rO0BkhK8xxQhytJ=Sdc2-2yQcH@mail.gmail.com>
	<AANLkTi=CHyYc3wUjwpOOuvOuD4Zjz6pO02YWrYcPc2L3@mail.gmail.com>
	<4D715621.8050800@paradise.net.nz>
	<AANLkTi=fKG+ykh1vyb021TYTPYGCdkDB_HAjB-2Veaok@mail.gmail.com>
	<AANLkTikZfjGBK876ES4p4TpthGEdcBijUL7yXWC9yqkL@mail.gmail.com>
	<AANLkTi=uOHmmapVcvzCTTTzP7Lsk4+XN-JMEbO94HECo@mail.gmail.com>
	<1299705438.4d77ee5edbf35@www.paradise.net.nz>
Message-ID: <AANLkTikiYTXX1a1MvkMomE1c_fip=s5dJZu0LqQVVRcr@mail.gmail.com>

The snippet implies this because it does something with 'r' when an
exception occurs, hence strongly suggesting that the author expected
"SomeException" to occur in the body of the try and not on the initializing
expression. (See quoted post below for context). The point I was trying to
make is: This is simply an alternative interpretation of the ARM block, and
one that is not *currently* compatible with how ARM is specified. Whether or
not its a use case that needs catering to is not something I commented on,
but I did attempt to point out that *IF* this use case is deemed important,
*AND* the doubly-nested try block is deemed too unwieldy to cater to it,
that there's no way out but to either (A) introduce a keyword, or (B) define
that the variable is initialized to 'null' if the initializing expression
fails.

The remainder of your post seems to be based on the confusion that I was
somehow advocating for the alternative use-case, so I assume no further
clarifications are required.

Removing the ability to catch/finally on an ARM try probably doesn't make it
any easier to work with; programmers will naturally assume that, as the
keyword 'try' is used, that finally and catch are allowed to be tacked on.
Removing the ability to do so also means the keyword should change from
'try' to something else ('do' is the most likely target if no new keywords
are allowed to be added as per coin's manifesto). Such a drastic change is
probably no longer feasible for java 7 at this point in time. I'm also not
sure try is truly as complicated as its being made out in practice. The
common use cases pretty much all work on the basis that the initializing
expression is just as likely to throw an exception as the usage of the
resource itself, and there's nothing useful to be gained by having access to
the variable in the catch block.

 --Reinier Zwitserloot



On Wed, Mar 9, 2011 at 10:17 PM, <brucechapman at paradise.net.nz> wrote:

> Quoting Reinier Zwitserloot <reinier at zwitserloot.com>:
>
> > This snippet:
> >
> > try (Resource r = getResource()) {
> >  .....
> > } catch (SomeException e) {
> >  ... do something with r....
> > }
> >
> >
> > implies that getResource() is not expected to fail. This is quite
> > different
> > from for example an inputstream:
>
> implies how?
>
> Neal's post which you quote suggested to me the perspective that in t-w-r,
> any
> catch or finally clause is really about the resource initialisation (and
> closing), and NOT really (or at least not so much) about exceptions thrown
> in
> the block. If you want to catch exceptions in the block, use the nested try
> idiom suggested by Stephen's email and confirmed by Neal.  This is not
> obvious.
>  But your statement 'implies that getResource() is not expected to fail.'
> is not
> consistent with this perspective because you have a catch in the t-w-r,
> which
> signifies that you are expecting getResource() to fail (assuming any
> expected
> failure of close() doesn't need explicit handling).
>
> If the perspective above is correct (I am not saying it is - I am
> suggesting it
> might be), or at least leads to correct code, then maybe we should give a
> hint
> of that in the JSR spec so we (and people who will write books about this
> stuff,
> and people that will explain it to others) send people off in the right
> direction to start with.
>
> Then again, I may well be deluded.
>
> Bruce
>
> >
> > try (InputStream r = new FileInputStream(file)) { ... }
> >
> > where an exception on the constructor call is expected and the current
> > specified behaviour of ARM matches this expectation (notably: that it
> > includes the initializing expression as part of the 'try').
> >
> > There are a few solutions when the expectation is for the expression not
> > to
> > fail as in the getResource example:
> >
> > (1) Do *NOT* consider the expression as part of the 'try'. Short of
> > introducing some new keyword to specify which behaviour you want,
> > Stephen's
> > example of try (Resource r = ...) { try { ..... }} does exactly that,
> > and is
> > the only way to do this.
> >
> > (2) Allow both with the same try statement. However, as in practice any
> > expression can theoretically fail with any exception, the solution
> > would
> > have to be that 'r' is set to null if the initializing expression does
> > not
> > complete normally. The syntax sugar to make this work isn't trivial but
> > it
> > can be done.
> >
> > One could then write:
> >
> > try (Resource r = getResource()) {
> >  ....
> > } catch (Exception e) {
> >  icon = Icons.DEFAULT_ICON;
> >  logger.log("App icon resource " + r.getURL() + " is not available",
> > e);
> > }
> >
> > and if the exception that triggered the catch block to run occurred in
> > the
> > evaluation of "getResource()", the above code would produce an NPE on
> > the
> > log line. Better than a core dump, I guess. As with any null resource,
> > such
> > a resource will not be closed, and no exception is caused by the fact
> > that
> > 'r' is null when its time to clean it up. (which would be following the
> > execution of the catch block).
> >
> > Whether doing this is a good idea is something I leave to the readers,
> > but
> > it is another consistent alternative and does look slightly cleaner,
> > though
> > there's far more magic going on with this version.
> >
> >
> >  --Reinier Zwitserloot
> >
> >
> >
> > On Sat, Mar 5, 2011 at 9:18 PM, Neal Gafter <neal at gafter.com> wrote:
> >
> > > In the try-with-resource language construct, exceptions thrown during
> > the
> > > construction of the resource are caught in the catch clauses.
> > Therefore,
> > > making the resource in scope be within the catch clause would be
> > providing
> > > access to a variable that is not definitely assigned. Since a
> > variable
> > > that
> > > is final (by the try-with-resources specification), not definitely
> > assigned
> > > (because the exception might have occurred during the resource
> > expression),
> > > and not definitely unassigned (because the exception might have
> > occurred
> > > during the try block), it cannot be used in any way. There is
> > therefore no
> > > point in making the variable be in scope within the catch clause.
> > >
> > > The correct thing to do is Stephen' suggestion:
> > >
> > > On Sat, Mar 5, 2011 at 11:08 AM, Stephen Colebourne
> > <scolebourne at joda.org
> > > >wrote:
> > >
> > > > But there is a "hack" solution:
> > > >
> > > > try(Resource r = getResource()) {try {
> > > > doSomething(r);
> > > > } catch (ResourceException e) {
> > > > System.out.println(e + " from " + r); // r undefined here
> > > > }}
> > > >
> > > > Not ideal.
> > > >
> > >
> > > This is the correct solution, and it is both ideal and not a hack. I'm
> > not
> > > sure I agree with your spacing and placement of curly braces, but that
> > is a
> > > style issue. The semantics of this code are different (than a catch on
> > the
> > > try-with-resources statement) because the catch clause here only
> > catches
> > > exceptions thrown from within the inner try block. If you want to use
> > the
> > > resource variable, that is exactly what you need.
> > >
> > > At worst, this exchange demonstrates that the try-with-resources
> > > specification is piling too much complexity on the already overly
> > complex
> > > try statement.
> > >
> > > Cheers,
> > > Neal
> > >
> > >
> >
> >
>
>
>


From joe.darcy at oracle.com  Sun Mar 13 19:02:11 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 13 Mar 2011 19:02:11 -0700
Subject: ARM and thread interruption
In-Reply-To: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
Message-ID: <4D7D7723.4070803@oracle.com>

Hello Mike.

After due consideration and after consulting with the concurrency mavens 
on the JSR 166 expert group, the JSR 334 expert group has decided it is 
sufficient for the specification of the AutoCloseable type to strongly 
warn against having AutoCloseable.close throw InterruptedException at 
runtime.  Additionally, javac and other compilers may warn against 
declaring an AutoCloseable.close method which throws InterruptedException. 

Thank you for raising this issue; regards,

-Joe

Mike Clark wrote:
> I am little concerned about ARM suppressing
> java.lang.InterruptedException and thread interruption status.   When
> a thread is interrupted, its interrupt flag is set to true until an
> InterruptedException can be raised and the interrupt flag reset.  It
> is notable that the interrupt flag is reset after an
> InterruptedException has been raised, because then the only remaining
> indication that an interrupt occurred is the presence of the
> InterruptedException.  Now consider that in an ARM block, the
> InterruptedException may be relegated to a collection of suppressed
> exceptions.  In this case, today's existing code would not notice the
> InterruptedException and thus may not notice that its thread was
> interrupted, preventing the thread from taking its interruption code
> path.
>
> Of course this problem of exception priority is present amongst any
> two exceptions that occur during ARM -- not just
> InterruptedExceptions.  However, because InterruptedException plays a
> special role in the runtime's threading model, I think perhaps this
> particular case may be worth considering on its own.
>
> Code which must be responsive to interruption might need to introduce
> a third strategy: upon catching an exception, it could iterate over
> the suppressed exceptions and search for an exception that is
> instanceof InterruptedException.  If such an exception is present, the
> code can assume that an interrupt occurred.  The problem with this
> approach is a problem of ownership of the interruption policy of the
> thread.  Before suppressed InterruptedExceptions, we could trust that,
> in general, a InterruptedException would travel up to code that
> implemented the thread's interruption policy.   Now the
> InterruptedException may end up in a lower-level catch block, as a
> suppressed throwable of some other type of exception.  And that catch
> block may not even know to search for the InterruptedException, let
> alone what to do with it.  That catch block may be in code that you do
> not control.
>
> One idea I was thinking about was having ARM blocks re-assert the
> interrupt status on a thread if the ARM block knows that it suppressed
> an InterruptedException.  This wouldn't stop InterruptedExceptions
> from sometimes getting relegated to suppressed exceptions, but it
> would at least give the thread a second chance to assert a new
> InterruptedException at a later statement.
>
> I am not sure exactly what to do about this particular issue.  I
> realize this is all a bit of an edge case, but as someone who has
> written (and fixed) a lot of thread-interrupt code, it does concern me
> a little, and I wanted to at least see if anyone else thinks this an
> issue worth discussing.
>
> best regards,
> Mike
>
>   



From peter.levart at gmail.com  Mon Mar 14 10:55:34 2011
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 14 Mar 2011 18:55:34 +0100
Subject: ARM and thread interruption
In-Reply-To: <4D7D7723.4070803@oracle.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
	<4D7D7723.4070803@oracle.com>
Message-ID: <201103141855.35084.peter.levart@gmail.com>

On Monday, March 14, 2011 03:02:11 am Joe Darcy wrote:
> Hello Mike.
> 
> After due consideration and after consulting with the concurrency mavens
> on the JSR 166 expert group, the JSR 334 expert group has decided it is
> sufficient for the specification of the AutoCloseable type to strongly
> warn against having AutoCloseable.close throw InterruptedException at
> runtime.  Additionally, javac and other compilers may warn against
> declaring an AutoCloseable.close method which throws InterruptedException.
> 
> Thank you for raising this issue; regards,
> 
> -Joe

What about InterruptedIOException?

see below...

> 
> Mike Clark wrote:
> > I am little concerned about ARM suppressing
> > java.lang.InterruptedException and thread interruption status.   When
> > a thread is interrupted, its interrupt flag is set to true until an
> > InterruptedException can be raised and the interrupt flag reset.  It
> > is notable that the interrupt flag is reset after an
> > InterruptedException has been raised, because then the only remaining
> > indication that an interrupt occurred is the presence of the
> > InterruptedException.  Now consider that in an ARM block, the
> > InterruptedException may be relegated to a collection of suppressed
> > exceptions.  In this case, today's existing code would not notice the
> > InterruptedException and thus may not notice that its thread was
> > interrupted, preventing the thread from taking its interruption code
> > path.
> > 
> > Of course this problem of exception priority is present amongst any
> > two exceptions that occur during ARM -- not just
> > InterruptedExceptions.  However, because InterruptedException plays a
> > special role in the runtime's threading model, I think perhaps this
> > particular case may be worth considering on its own.
> > 
> > Code which must be responsive to interruption might need to introduce
> > a third strategy: upon catching an exception, it could iterate over
> > the suppressed exceptions and search for an exception that is
> > instanceof InterruptedException.  If such an exception is present, the
> > code can assume that an interrupt occurred.  The problem with this
> > approach is a problem of ownership of the interruption policy of the
> > thread.  Before suppressed InterruptedExceptions, we could trust that,
> > in general, a InterruptedException would travel up to code that
> > implemented the thread's interruption policy.  

What about interruption of read/write and also close on IO streams? The javadoc for 
InterruptedIOException says:

Signals that an I/O operation has been interrupted. An InterruptedIOException is thrown to 
indicate that an input or output transfer has been terminated because the thread performing it 
was interrupted. The field bytesTransferred indicates how many bytes were successfully 
transferred before the interruption occurred.


Regards, Peter

> > Now the
> > InterruptedException may end up in a lower-level catch block, as a
> > suppressed throwable of some other type of exception.  And that catch
> > block may not even know to search for the InterruptedException, let
> > alone what to do with it.  That catch block may be in code that you do
> > not control.
> > 
> > One idea I was thinking about was having ARM blocks re-assert the
> > interrupt status on a thread if the ARM block knows that it suppressed
> > an InterruptedException.  This wouldn't stop InterruptedExceptions
> > from sometimes getting relegated to suppressed exceptions, but it
> > would at least give the thread a second chance to assert a new
> > InterruptedException at a later statement.
> > 
> > I am not sure exactly what to do about this particular issue.  I
> > realize this is all a bit of an edge case, but as someone who has
> > written (and fixed) a lot of thread-interrupt code, it does concern me
> > a little, and I wanted to at least see if anyone else thinks this an
> > issue worth discussing.
> > 
> > best regards,
> > Mike


From joe.darcy at oracle.com  Mon Mar 14 11:07:43 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 14 Mar 2011 11:07:43 -0700
Subject: ARM and thread interruption
In-Reply-To: <201103141855.35084.peter.levart@gmail.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
	<4D7D7723.4070803@oracle.com>
	<201103141855.35084.peter.levart@gmail.com>
Message-ID: <4D7E596F.8060605@oracle.com>

Peter Levart wrote:
>
> On Monday, March 14, 2011 03:02:11 am Joe Darcy wrote:
>
> > Hello Mike.
>
> >
>
> > After due consideration and after consulting with the concurrency mavens
>
> > on the JSR 166 expert group, the JSR 334 expert group has decided it is
>
> > sufficient for the specification of the AutoCloseable type to strongly
>
> > warn against having AutoCloseable.close throw InterruptedException at
>
> > runtime. Additionally, javac and other compilers may warn against
>
> > declaring an AutoCloseable.close method which throws 
> InterruptedException.
>
> >
>
> > Thank you for raising this issue; regards,
>
> >
>
> > -Joe
>
> What about InterruptedIOException?
>
> see below...
>

The try-with-resource construct does not give special handling to any 
exception type.

-Joe


From tim at peierls.net  Mon Mar 14 11:55:33 2011
From: tim at peierls.net (Tim Peierls)
Date: Mon, 14 Mar 2011 14:55:33 -0400
Subject: ARM and thread interruption
In-Reply-To: <4D7E596F.8060605@oracle.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
	<4D7D7723.4070803@oracle.com>
	<201103141855.35084.peter.levart@gmail.com>
	<4D7E596F.8060605@oracle.com>
Message-ID: <AANLkTikOAm7EAnwy0VSYqj_9E_siYyjoVzpRweNWdyns@mail.gmail.com>

I think the question was whether the spec would warn against
AutoCloseable.close with other kinds of exceptions besides IE, and the
answer (as of this writing) is "only in general terms".

--tim

On Mon, Mar 14, 2011 at 2:07 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Peter Levart wrote:
> >
> > On Monday, March 14, 2011 03:02:11 am Joe Darcy wrote:
> >
> > > Hello Mike.
> >
> > >
> >
> > > After due consideration and after consulting with the concurrency
> mavens
> >
> > > on the JSR 166 expert group, the JSR 334 expert group has decided it is
> >
> > > sufficient for the specification of the AutoCloseable type to strongly
> >
> > > warn against having AutoCloseable.close throw InterruptedException at
> >
> > > runtime. Additionally, javac and other compilers may warn against
> >
> > > declaring an AutoCloseable.close method which throws
> > InterruptedException.
> >
> > >
> >
> > > Thank you for raising this issue; regards,
> >
> > >
> >
> > > -Joe
> >
> > What about InterruptedIOException?
> >
> > see below...
> >
>
> The try-with-resource construct does not give special handling to any
> exception type.
>
> -Joe
>
>


From David.Holmes at oracle.com  Mon Mar 14 13:41:21 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2011 06:41:21 +1000
Subject: ARM and thread interruption
In-Reply-To: <AANLkTikOAm7EAnwy0VSYqj_9E_siYyjoVzpRweNWdyns@mail.gmail.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>	<4D7D7723.4070803@oracle.com>	<201103141855.35084.peter.levart@gmail.com>	<4D7E596F.8060605@oracle.com>
	<AANLkTikOAm7EAnwy0VSYqj_9E_siYyjoVzpRweNWdyns@mail.gmail.com>
Message-ID: <4D7E7D71.2010100@oracle.com>

Tim Peierls said the following on 03/15/11 04:55:
> I think the question was whether the spec would warn against
> AutoCloseable.close with other kinds of exceptions besides IE, and the
> answer (as of this writing) is "only in general terms".

And a general consideration here is that if your close() method can 
throw significant/interesting exceptions, which by definition of the 
try-with-resources construct will get suppressed when an exception 
occurs in the main block, then perhaps what you are defining should not 
be an AutoCloseable.

David

> --tim
> 
> On Mon, Mar 14, 2011 at 2:07 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
>> Peter Levart wrote:
>>> On Monday, March 14, 2011 03:02:11 am Joe Darcy wrote:
>>>
>>>> Hello Mike.
>>>> After due consideration and after consulting with the concurrency
>> mavens
>>>> on the JSR 166 expert group, the JSR 334 expert group has decided it is
>>>> sufficient for the specification of the AutoCloseable type to strongly
>>>> warn against having AutoCloseable.close throw InterruptedException at
>>>> runtime. Additionally, javac and other compilers may warn against
>>>> declaring an AutoCloseable.close method which throws
>>> InterruptedException.
>>>
>>>> Thank you for raising this issue; regards,
>>>> -Joe
>>> What about InterruptedIOException?
>>>
>>> see below...
>>>
>> The try-with-resource construct does not give special handling to any
>> exception type.
>>
>> -Joe
>>
>>
> 


From joe.darcy at oracle.com  Mon Mar 14 13:53:36 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 14 Mar 2011 13:53:36 -0700
Subject: ARM and thread interruption
In-Reply-To: <4D7E7D71.2010100@oracle.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>	<4D7D7723.4070803@oracle.com>	<201103141855.35084.peter.levart@gmail.com>	<4D7E596F.8060605@oracle.com>	<AANLkTikOAm7EAnwy0VSYqj_9E_siYyjoVzpRweNWdyns@mail.gmail.com>
	<4D7E7D71.2010100@oracle.com>
Message-ID: <4D7E8050.6030704@oracle.com>

On 3/14/2011 1:41 PM, David Holmes wrote:
> Tim Peierls said the following on 03/15/11 04:55:
>> I think the question was whether the spec would warn against
>> AutoCloseable.close with other kinds of exceptions besides IE, and the
>> answer (as of this writing) is "only in general terms".
> And a general consideration here is that if your close() method can
> throw significant/interesting exceptions, which by definition of the
> try-with-resources construct will get suppressed when an exception
> occurs in the main block, then perhaps what you are defining should not
> be an AutoCloseable.
>
> David
>

Yes, the changeset implementing the javadoc change [1], includes a 
warning along those lines:

--- a/src/share/classes/java/lang/AutoCloseable.java    Mon Mar 14 
18:13:32 2011 +0000
+++ b/src/share/classes/java/lang/AutoCloseable.java    Mon Mar 14 
11:45:21 2011 -0700
@@ -34,12 +34,27 @@ public interface AutoCloseable {
  public interface AutoCloseable {
      /**
       * Closes this resource, relinquishing any underlying resources.
-     * This method is invoked automatically by the {@code
-     * try}-with-resources statement.
+     * This method is invoked automatically on objects managed by the
+     * {@code try}-with-resources statement.
       *
-     * <p>Classes implementing this method are strongly encouraged to
-     * be declared to throw more specific exceptions (or no exception
-     * at all, if the close cannot fail).
+     * <p>While this interface method is declared to throw {@code
+     * Exception}, implementers are <em>strongly</em> encouraged to
+     * declare concrete implementations of the {@code close} method to
+     * throw more specific exceptions, or to throw no exception at all
+     * if the close operation cannot fail.
+     *
+     * <p><em>Implementers of this interface are also strongly advised
+     * to not have the {@code close} method throw {@link
+     * InterruptedException}.</em>
+     *
+     * This exception interacts with a thread's interrupted status,
+     * and runtime misbehavior is likely to occur if an {@code
+     * InterruptedException} is {@linkplain Throwable#addSuppressed
+     * suppressed}.
+     *
+     * More generally, if it would cause problems for an
+     * exception to be suppressed, the {@code AutoCloseable.close}
+     * method should not throw it.
       *
       * <p>Note that unlike the {@link java.io.Closeable#close close}
       * method of {@link java.io.Closeable}, this {@code close} method
@@ -48,9 +63,8 @@ public interface AutoCloseable {
       * visible side effect, unlike {@code Closeable.close} which is
       * required to have no effect if called more than once.
       *
-     * However, while not required to be idempotent, implementers of
-     * this interface are strongly encouraged to make their {@code
-     * close} methods idempotent.
+     * However, implementers of this interface are strongly encouraged
+     * to make their {@code close} methods idempotent.
       *
       * @throws Exception if this resource cannot be closed
       */


-Joe

[1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1924a21184a6


From pbenedict at apache.org  Mon Mar 14 14:35:16 2011
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 14 Mar 2011 16:35:16 -0500
Subject: ARM and thread interruption
In-Reply-To: <4D7E8050.6030704@oracle.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
	<4D7D7723.4070803@oracle.com>
	<201103141855.35084.peter.levart@gmail.com>
	<4D7E596F.8060605@oracle.com>
	<AANLkTikOAm7EAnwy0VSYqj_9E_siYyjoVzpRweNWdyns@mail.gmail.com>
	<4D7E7D71.2010100@oracle.com> <4D7E8050.6030704@oracle.com>
Message-ID: <AANLkTikLBGww6w0ZoKKu1qHgYC+MqEndZCYXBAQUOxWF@mail.gmail.com>

FWIW, I think David's wording is more clear than the addition to the
javadoc.

Paul

On Mon, Mar 14, 2011 at 3:53 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> On 3/14/2011 1:41 PM, David Holmes wrote:
> > Tim Peierls said the following on 03/15/11 04:55:
> >> I think the question was whether the spec would warn against
> >> AutoCloseable.close with other kinds of exceptions besides IE, and the
> >> answer (as of this writing) is "only in general terms".
> > And a general consideration here is that if your close() method can
> > throw significant/interesting exceptions, which by definition of the
> > try-with-resources construct will get suppressed when an exception
> > occurs in the main block, then perhaps what you are defining should not
> > be an AutoCloseable.
> >
> > David
> >
>
> Yes, the changeset implementing the javadoc change [1], includes a
> warning along those lines:
>
> --- a/src/share/classes/java/lang/AutoCloseable.java    Mon Mar 14
> 18:13:32 2011 +0000
> +++ b/src/share/classes/java/lang/AutoCloseable.java    Mon Mar 14
> 11:45:21 2011 -0700
> @@ -34,12 +34,27 @@ public interface AutoCloseable {
>  public interface AutoCloseable {
>      /**
>       * Closes this resource, relinquishing any underlying resources.
> -     * This method is invoked automatically by the {@code
> -     * try}-with-resources statement.
> +     * This method is invoked automatically on objects managed by the
> +     * {@code try}-with-resources statement.
>       *
> -     * <p>Classes implementing this method are strongly encouraged to
> -     * be declared to throw more specific exceptions (or no exception
> -     * at all, if the close cannot fail).
> +     * <p>While this interface method is declared to throw {@code
> +     * Exception}, implementers are <em>strongly</em> encouraged to
> +     * declare concrete implementations of the {@code close} method to
> +     * throw more specific exceptions, or to throw no exception at all
> +     * if the close operation cannot fail.
> +     *
> +     * <p><em>Implementers of this interface are also strongly advised
> +     * to not have the {@code close} method throw {@link
> +     * InterruptedException}.</em>
> +     *
> +     * This exception interacts with a thread's interrupted status,
> +     * and runtime misbehavior is likely to occur if an {@code
> +     * InterruptedException} is {@linkplain Throwable#addSuppressed
> +     * suppressed}.
> +     *
> +     * More generally, if it would cause problems for an
> +     * exception to be suppressed, the {@code AutoCloseable.close}
> +     * method should not throw it.
>       *
>       * <p>Note that unlike the {@link java.io.Closeable#close close}
>       * method of {@link java.io.Closeable}, this {@code close} method
> @@ -48,9 +63,8 @@ public interface AutoCloseable {
>       * visible side effect, unlike {@code Closeable.close} which is
>       * required to have no effect if called more than once.
>       *
> -     * However, while not required to be idempotent, implementers of
> -     * this interface are strongly encouraged to make their {@code
> -     * close} methods idempotent.
> +     * However, implementers of this interface are strongly encouraged
> +     * to make their {@code close} methods idempotent.
>       *
>       * @throws Exception if this resource cannot be closed
>       */
>
>
> -Joe
>
> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1924a21184a6
>
>


From mclark at apache.org  Tue Mar 15 16:57:09 2011
From: mclark at apache.org (Mike Clark)
Date: Tue, 15 Mar 2011 17:57:09 -0600
Subject: ARM and thread interruption
In-Reply-To: <4D7D7723.4070803@oracle.com>
References: <AANLkTim0xYKsumPHHEeSND5dREb8FV7COmAX0dYkSmvG@mail.gmail.com>
	<4D7D7723.4070803@oracle.com>
Message-ID: <AANLkTikokCvPdQgHNV1xi5+Lb2qTFnr-YXi=LB32+uPj@mail.gmail.com>

On Sun, Mar 13, 2011 at 8:02 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello Mike.
>
> After due consideration and after consulting with the concurrency mavens on
> the JSR 166 expert group, the JSR 334 expert group has decided it is
> sufficient for the specification of the AutoCloseable type to strongly warn
> against having AutoCloseable.close throw InterruptedException at runtime.
>  Additionally, javac and other compilers may warn against declaring an
> AutoCloseable.close method which throws InterruptedException.
> Thank you for raising this issue; regards,
>
> -Joe


Hi Joe,

Thanks.  All things considered, I agree that the documentation note is a
reasonable response to this issue, given its scope.   In the context of
larger systems, thread interruption seems to degrade to being a "best
effort" tool anyway, rather than a tool with hard and fast guarantees.

best regards,
Mike


From joe.darcy at oracle.com  Thu Mar 24 14:04:33 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 24 Mar 2011 14:04:33 -0700
Subject: FYI, JSR 334 is now in public review
Message-ID: <4D8BB1E1.6000309@oracle.com>

Hello.

FYI, JSR 334 is now in public review and the public review draft of the 
specification, v0.875, can be downloaded from:
http://jcp.org/aboutJava/communityprocess/pr/jsr334/index.html

-Joe


From neal at gafter.com  Thu Mar 24 15:37:41 2011
From: neal at gafter.com (Neal Gafter)
Date: Thu, 24 Mar 2011 15:37:41 -0700
Subject: FYI, JSR 334 is now in public review
In-Reply-To: <4D8BB1E1.6000309@oracle.com>
References: <4D8BB1E1.6000309@oracle.com>
Message-ID: <AANLkTimptfpN8r4GULfDwQea573tkuFHMG4jua+Y383y@mail.gmail.com>

Joe-

Please provide access to the archives of the expert group mailing list.

Cheers,
Neal

On Thu, Mar 24, 2011 at 2:04 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello.
>
> FYI, JSR 334 is now in public review and the public review draft of the
> specification, v0.875, can be downloaded from:
> http://jcp.org/aboutJava/communityprocess/pr/jsr334/index.html
>
> -Joe
>
>


From bernard.traversat at oracle.com  Thu Mar 31 21:41:33 2011
From: bernard.traversat at oracle.com (Bernard Traversat)
Date: Thu, 31 Mar 2011 21:41:33 -0700
Subject: FYI, JSR 334 is now in public review
In-Reply-To: <AANLkTimptfpN8r4GULfDwQea573tkuFHMG4jua+Y383y@mail.gmail.com>
References: <4D8BB1E1.6000309@oracle.com>
	<AANLkTimptfpN8r4GULfDwQea573tkuFHMG4jua+Y383y@mail.gmail.com>
Message-ID: <4D95577D.7050102@oracle.com>

  On 3/24/11 3:37 PM, Neal Gafter wrote:
> Joe-
>
> Please provide access to the archives of the expert group mailing list.
We are working on it and committed to a transparent process.

Cheers,

B.
> Cheers,
> Neal
>
> On Thu, Mar 24, 2011 at 2:04 PM, Joe Darcy<joe.darcy at oracle.com>  wrote:
>
>> Hello.
>>
>> FYI, JSR 334 is now in public review and the public review draft of the
>> specification, v0.875, can be downloaded from:
>> http://jcp.org/aboutJava/communityprocess/pr/jsr334/index.html
>>
>> -Joe
>>
>>