From joe.darcy at oracle.com  Tue Jun  7 10:06:51 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 07 Jun 2011 10:06:51 -0700
Subject: JDK7 language specification issue with MethodHandle
In-Reply-To: <BANLkTimbJCAgtxKF93NKBSk+tanUQE4vpw@mail.gmail.com>
References: <BANLkTiku_xOmuTSsCiF3shdut_91VenRBg@mail.gmail.com>	<4D9AD1B4.7020402@univ-mlv.fr>
	<BANLkTimbJCAgtxKF93NKBSk+tanUQE4vpw@mail.gmail.com>
Message-ID: <4DEE5AAB.2060206@oracle.com>

Neal Gafter wrote:
> On Tue, Apr 5, 2011 at 1:24 AM, R?mi Forax <forax at univ-mlv.fr> wrote:
>
>   
>> You're right that these changes was first submitted to coin,
>> but it was latter decided that the only the syntax change implemented
>> in Java 7, invoking a method handle, will be done under JSR 292.
>>
>>     
>
> Can you please send me a pointer to the minutes for that JCP EC vote?  The
> public page for jsr292 doesn't give any evidence that the EC accepted the
> expansion of jsr292's scope beyond VM specification changes.
>
>   

The JCP SE/EE executive committee voted to approve the JSR 336 public review

    http://www.jcp.org/en/jsr/results?id=5207

and the JSR 336 public review describes JSR 292 as including Java 
language changes.

-Joe


From neal at gafter.com  Tue Jun  7 13:17:09 2011
From: neal at gafter.com (Neal Gafter)
Date: Tue, 7 Jun 2011 13:17:09 -0700
Subject: JDK7 language specification issue with MethodHandle
In-Reply-To: <4DEE5AAB.2060206@oracle.com>
References: <BANLkTiku_xOmuTSsCiF3shdut_91VenRBg@mail.gmail.com>
	<4D9AD1B4.7020402@univ-mlv.fr>
	<BANLkTimbJCAgtxKF93NKBSk+tanUQE4vpw@mail.gmail.com>
	<4DEE5AAB.2060206@oracle.com>
Message-ID: <BANLkTimXZYPYAbRok4WdedS7E5ghxXnA7A@mail.gmail.com>

On Tue, Jun 7, 2011 at 10:06 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

>  The JCP SE/EE executive committee voted to approve the JSR 336 public
> review
>
>   http://www.jcp.org/en/jsr/results?id=5207
>
> and the JSR 336 public review describes JSR 292 as including Java language
> changes.
>

*The jsr292 specification which was published for public review does not
propose any changes to the Java Language Specification.*

You said on April 18 that "Changes to the JSR 292 specification to clarify
[sic] the Java language changes that support MethodHandle are in process".
 That process appears not to have occurred, as there are no further public
drafts of the jsr292 specification.

The jsr336 specification doesn't propose any changes to the Java Language
Specification either, other than pointing to other jsrs.

jsr901, the language "maintenance" jsr, does specify language changes, but
it has no independent approval process.  The public review period for its
changes coincided with an outage in Oracle's public website for viewing the
issues it is alleged to address, which made impossible any practical review
of the changes. In any case, jsr901 contains no jsr292-related changes such
as polymorphic method signatures.

Of course, with no public access to the expert group discussions it is very
hard for me to know precisely what it was that was decided in either case.
 But based on the documents that have been published, jsr336 didn't appear
to approve for inclusion into SE 7 any language changes that relate to
jsr292.

Cheers,
Neal


From joe.darcy at oracle.com  Fri Jun 10 12:10:41 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 10 Jun 2011 12:10:41 -0700
Subject: JDK7 language specification issue with MethodHandle
In-Reply-To: <BANLkTimXZYPYAbRok4WdedS7E5ghxXnA7A@mail.gmail.com>
References: <BANLkTiku_xOmuTSsCiF3shdut_91VenRBg@mail.gmail.com>
	<4D9AD1B4.7020402@univ-mlv.fr>
	<BANLkTimbJCAgtxKF93NKBSk+tanUQE4vpw@mail.gmail.com>
	<4DEE5AAB.2060206@oracle.com>
	<BANLkTimXZYPYAbRok4WdedS7E5ghxXnA7A@mail.gmail.com>
Message-ID: <4DF26C31.3050600@oracle.com>

Hi Neal.

Neal Gafter wrote:
> On Tue, Jun 7, 2011 at 10:06 AM, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     The JCP SE/EE executive committee voted to approve the JSR 336
>     public review
>
>       http://www.jcp.org/en/jsr/results?id=5207
>
>     and the JSR 336 public review describes JSR 292 as including Java
>     language changes.
>
>
> *The jsr292 specification which was published for public review does 
> not propose any changes to the Java Language Specification.*
>
> You said on April 18 that "Changes to the JSR 292 specification to 
> clarify [sic] the Java language changes that support MethodHandle are 
> in process".  That process appears not to have occurred, as there are 
> no further public drafts of the jsr292 specification.
>
> The jsr336 specification doesn't propose any changes to the Java 
> Language Specification either, other than pointing to other jsrs.
>
> jsr901, the language "maintenance" jsr, does specify language changes, 
> but it has no independent approval process.  The public review period 
> for its changes coincided with an outage in Oracle's public website 
> for viewing the issues it is alleged to address, which made impossible 
> any practical review of the changes. In any case, jsr901 contains no 
> jsr292-related changes such as polymorphic method signatures.
>
> Of course, with no public access to the expert group discussions it is 
> very hard for me to know precisely what it was that was decided in 
> either case.  But based on the documents that have been published, 
> jsr336 didn't appear to approve for inclusion into SE 7 any language 
> changes that relate to jsr292.
>
> Cheers,
> Neal

The javadoc of the JSR 292 Public Review identified changes to the JVM 
Specification and discussed method handle invocation from the Java 
language.  Admittedly the review could have done a better job of 
explicitly calling out the implied Java Language Specification changes.

The forthcoming JSR 292 Proposed Final Draft will identify in detail its 
changes to both the JVM Specification and the Java Language Specification.

The JVMS and JLS Maintenance Reviews earlier in 2011 were not related to 
JSR 292.  Specifically, changes to casting conversion that turn out to 
be of use to JSR 292 were proposed independently years ago, see 
http://bugs.sun.com/view_bug.do?bug_id=6526446.

The JVMS and JLS updated for JSR 292 (and JSR 334) will included as part 
of JSR 336's Proposed Final Draft; those specifications will also 
reflect the accumulated maintenance changes from JSR 901, etc.

-Joe




From neal at gafter.com  Fri Jun 10 15:35:54 2011
From: neal at gafter.com (Neal Gafter)
Date: Fri, 10 Jun 2011 15:35:54 -0700
Subject: JDK7 language specification issue with MethodHandle
In-Reply-To: <4DF26C31.3050600@oracle.com>
References: <BANLkTiku_xOmuTSsCiF3shdut_91VenRBg@mail.gmail.com>
	<4D9AD1B4.7020402@univ-mlv.fr>
	<BANLkTimbJCAgtxKF93NKBSk+tanUQE4vpw@mail.gmail.com>
	<4DEE5AAB.2060206@oracle.com>
	<BANLkTimXZYPYAbRok4WdedS7E5ghxXnA7A@mail.gmail.com>
	<4DF26C31.3050600@oracle.com>
Message-ID: <BANLkTi=3Vo7HjXi0wKQAnRm==ON6xA3VNQ@mail.gmail.com>

On Fri, Jun 10, 2011 at 12:10 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> The javadoc of the JSR 292 Public Review identified changes to the JVM
> Specification and discussed method handle invocation from the Java language.
>  Admittedly the review could have done a better job of explicitly calling
> out the implied Java Language Specification changes.
>

I would have said "alluded to" rather than "identified".  There are no
specific changes called out.


> The forthcoming JSR 292 Proposed Final Draft will identify in detail its
> changes to both the JVM Specification and the Java Language Specification.
>

Isn't it late in the process to begin specifying language changes?  As
language changes are the most delicate and difficult to retract changes in
the platform, how many months of review do you anticipate once the proposed
language spec changes.have been published?

Cheers,
Neal


From siegmaralber at gmail.com  Wed Jun 15 07:54:01 2011
From: siegmaralber at gmail.com (Siegmar Alber)
Date: Wed, 15 Jun 2011 16:54:01 +0200
Subject: Typo in project coin documentation
Message-ID: <A4FFBDE8-B069-4B3C-8AB5-D4D9ED288DEF@gmail.com>

Hello,

I would like to let you know that there is a typo in the project coin documentation[1]:

In the section "Multi-catch and more precise rethrow" in the addition to JLSv3 ?11.2.3:

"The the purposes of exception checking..."
     ^^^

-- 
Thank you and have fun,
Siegmar

[1] http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html



From joe.darcy at oracle.com  Sat Jun 18 19:32:35 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 18 Jun 2011 19:32:35 -0700
Subject: Typo in project coin documentation
In-Reply-To: <A4FFBDE8-B069-4B3C-8AB5-D4D9ED288DEF@gmail.com>
References: <A4FFBDE8-B069-4B3C-8AB5-D4D9ED288DEF@gmail.com>
Message-ID: <4DFD5FC3.9020300@oracle.com>

Siegmar Alber wrote:
> Hello,
>
> I would like to let you know that there is a typo in the project coin documentation[1]:
>
> In the section "Multi-catch and more precise rethrow" in the addition to JLSv3 ?11.2.3:
>
> "The the purposes of exception checking..."
>      ^^^
>   

Hello Siegmar.

Thank you for reporting that problem; it will not appear in the final 
JLS changes for Coin.

Cheers,

-Joe


From vapor1 at teleport.com  Thu Jun 23 18:56:30 2011
From: vapor1 at teleport.com (Derek Foster)
Date: Thu, 23 Jun 2011 18:56:30 -0700 (GMT-07:00)
Subject: Diamond operator and anonymous classes
Message-ID: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>

Hi, folks.

I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.

As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:

   private final List<Integer> foo = new ArrayList<>();

and in anonymous class declarations such as:

   public static final Callable<Integer> TASK = new Callable<>() {
      public Integer call() {
          return doSomething();
      } 
   };

However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)

I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.) 

In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:

class MyNiftyClass {
public static final Comparator<MyNiftyClass> FORWARD = new Comparator<MyNiftyClass>() {
    @Override
    public int compare(MyNiftyClass first, MyNiftyClass second) {
        ... comparator logic goes here ...
    }
};
public static final Comparator<MyNiftyClass> BACKWARD = new Comparator<MyNiftyClass>() {
    @Override
    public int compare(MyNiftyClass first, MyNiftyClass second) {
        return FORWARD.compare(second, first);
    }
};
...
}


In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:

// One member of a large hierarchy of items that have a similar structure
class NativeColorWrapper extends NativeObject {

   // A public factory for creating instances of NativeColorWrapper by wrapping a native
   // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
   // is used for all instance creation.
   public static final NativeFactory<INativeUnboundContext, NativeColorWrapper> FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
       @Override
       public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
           return new NativeColorWrapper(context, nativePointer);
       }
   };

   // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
   // There are multiple instances of these caches, with various differing generic
   // parameter types depending on the data to be cached.
   private final LazyMap<NativeIdentifier, SortedSet<NativeItem>> _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
       protected SortedSet<NativeItem> fetch(NativeIdentifier binding) {
           long[] nativePointers = someNativeMethod(binding.toString());
           return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
       }
   };
   ...
}

A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.

This is backed up to some degree by bug reports such as this one:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753

Which states:

"
In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.

There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
"

It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:

The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")

Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.

Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)

Thanks for any information.

Derek



From David.Holmes at oracle.com  Fri Jun 24 01:03:01 2011
From: David.Holmes at oracle.com (David Holmes)
Date: Fri, 24 Jun 2011 18:03:01 +1000
Subject: Diamond operator and anonymous classes
In-Reply-To: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
References: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
Message-ID: <4E0444B5.6010003@oracle.com>

Derek,

This has been raised a couple of time already. The reasoning is given in 
the current Coin documentation (not sure if there's an official version 
yet):

http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html

where it states:

"Internally, a Java compiler operates over a richer set of types than 
those that can be written down explicitly in a Java program. The 
compiler-internal types which cannot be written in a Java program are 
called non-denotable types. Non-denotable types can occur as the result 
of the inference used by diamond. Therefore, using diamond with 
anonymous inner classes is not supported since doing so in general would 
require extensions to the class file signature attribute to represent 
non-denotable types, a de facto JVM change. It is feasible that future 
platform versions could allow use of diamond when creating an anonymous 
inner class as long as the inferred type was denotable. "

As you can see the door is open for relaxing the current rules in the 
future.

Cheers,
David Holmes

Derek Foster said the following on 06/24/11 11:56:
> Hi, folks.
> 
> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
> 
> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
> 
>    private final List<Integer> foo = new ArrayList<>();
> 
> and in anonymous class declarations such as:
> 
>    public static final Callable<Integer> TASK = new Callable<>() {
>       public Integer call() {
>           return doSomething();
>       } 
>    };
> 
> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
> 
> I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.) 
> 
> In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:
> 
> class MyNiftyClass {
> public static final Comparator<MyNiftyClass> FORWARD = new Comparator<MyNiftyClass>() {
>     @Override
>     public int compare(MyNiftyClass first, MyNiftyClass second) {
>         ... comparator logic goes here ...
>     }
> };
> public static final Comparator<MyNiftyClass> BACKWARD = new Comparator<MyNiftyClass>() {
>     @Override
>     public int compare(MyNiftyClass first, MyNiftyClass second) {
>         return FORWARD.compare(second, first);
>     }
> };
> ...
> }
> 
> 
> In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:
> 
> // One member of a large hierarchy of items that have a similar structure
> class NativeColorWrapper extends NativeObject {
> 
>    // A public factory for creating instances of NativeColorWrapper by wrapping a native
>    // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
>    // is used for all instance creation.
>    public static final NativeFactory<INativeUnboundContext, NativeColorWrapper> FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
>        @Override
>        public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
>            return new NativeColorWrapper(context, nativePointer);
>        }
>    };
> 
>    // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
>    // There are multiple instances of these caches, with various differing generic
>    // parameter types depending on the data to be cached.
>    private final LazyMap<NativeIdentifier, SortedSet<NativeItem>> _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
>        protected SortedSet<NativeItem> fetch(NativeIdentifier binding) {
>            long[] nativePointers = someNativeMethod(binding.toString());
>            return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
>        }
>    };
>    ...
> }
> 
> A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.
> 
> This is backed up to some degree by bug reports such as this one:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753
> 
> Which states:
> 
> "
> In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.
> 
> There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
> "
> 
> It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:
> 
> The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")
> 
> Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.
> 
> Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)
> 
> Thanks for any information.
> 
> Derek
> 
> 


From forax at univ-mlv.fr  Fri Jun 24 01:19:47 2011
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 24 Jun 2011 10:19:47 +0200
Subject: Diamond operator and anonymous classes
In-Reply-To: <4E0444B5.6010003@oracle.com>
References: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
	<4E0444B5.6010003@oracle.com>
Message-ID: <4E0448A3.4090300@univ-mlv.fr>

Your examples are lambdas, Java 8 will introduce a syntax for that.
By example,

public static final Comparator<MyNiftyClass>  BACKWARD = new Comparator<MyNiftyClass>() {
     @Override
     public int compare(MyNiftyClass first, MyNiftyClass second) {
         return FORWARD.compare(second, first);
     }
};

can be rewritten it to:

public static final Comparator<MyNiftyClass>  BACKWARD =
    #{ first, second ->  FORWARD.compare(second, first); };

or a similar syntax (this part is not frozen yet).

R?mi


On 06/24/2011 10:03 AM, David Holmes wrote:
> Derek,
>
> This has been raised a couple of time already. The reasoning is given in
> the current Coin documentation (not sure if there's an official version
> yet):
>
> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html
>
> where it states:
>
> "Internally, a Java compiler operates over a richer set of types than
> those that can be written down explicitly in a Java program. The
> compiler-internal types which cannot be written in a Java program are
> called non-denotable types. Non-denotable types can occur as the result
> of the inference used by diamond. Therefore, using diamond with
> anonymous inner classes is not supported since doing so in general would
> require extensions to the class file signature attribute to represent
> non-denotable types, a de facto JVM change. It is feasible that future
> platform versions could allow use of diamond when creating an anonymous
> inner class as long as the inferred type was denotable. "
>
> As you can see the door is open for relaxing the current rules in the
> future.
>
> Cheers,
> David Holmes
>
> Derek Foster said the following on 06/24/11 11:56:
>> Hi, folks.
>>
>> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
>>
>> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
>>
>>     private final List<Integer>  foo = new ArrayList<>();
>>
>> and in anonymous class declarations such as:
>>
>>     public static final Callable<Integer>  TASK = new Callable<>() {
>>        public Integer call() {
>>            return doSomething();
>>        }
>>     };
>>
>> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
>>
>> I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.)
>>
>> In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:
>>
>> class MyNiftyClass {
>> public static final Comparator<MyNiftyClass>  FORWARD = new Comparator<MyNiftyClass>() {
>>      @Override
>>      public int compare(MyNiftyClass first, MyNiftyClass second) {
>>          ... comparator logic goes here ...
>>      }
>> };
>> public static final Comparator<MyNiftyClass>  BACKWARD = new Comparator<MyNiftyClass>() {
>>      @Override
>>      public int compare(MyNiftyClass first, MyNiftyClass second) {
>>          return FORWARD.compare(second, first);
>>      }
>> };
>> ...
>> }
>>
>>
>> In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:
>>
>> // One member of a large hierarchy of items that have a similar structure
>> class NativeColorWrapper extends NativeObject {
>>
>>     // A public factory for creating instances of NativeColorWrapper by wrapping a native
>>     // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
>>     // is used for all instance creation.
>>     public static final NativeFactory<INativeUnboundContext, NativeColorWrapper>  FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
>>         @Override
>>         public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
>>             return new NativeColorWrapper(context, nativePointer);
>>         }
>>     };
>>
>>     // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
>>     // There are multiple instances of these caches, with various differing generic
>>     // parameter types depending on the data to be cached.
>>     private final LazyMap<NativeIdentifier, SortedSet<NativeItem>>  _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
>>         protected SortedSet<NativeItem>  fetch(NativeIdentifier binding) {
>>             long[] nativePointers = someNativeMethod(binding.toString());
>>             return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
>>         }
>>     };
>>     ...
>> }
>>
>> A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.
>>
>> This is backed up to some degree by bug reports such as this one:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753
>>
>> Which states:
>>
>> "
>> In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.
>>
>> There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
>> "
>>
>> It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:
>>
>> The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")
>>
>> Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.
>>
>> Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)
>>
>> Thanks for any information.
>>
>> Derek
>>
>>



From daniel.smith at oracle.com  Fri Jun 24 09:02:47 2011
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 24 Jun 2011 09:02:47 -0700
Subject: Diamond operator and anonymous classes
In-Reply-To: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
References: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
Message-ID: <87DBE361-B915-4F14-AE97-F6B8BBABC576@oracle.com>

The fundamental problem is that inference in this case is more than just inference of type arguments for a constructor call -- these are type arguments for an 'extends' clause, which impacts inheritance/overloading and the generated class file.

Motivating the deferral is that there were a few different ideas about how to handle this, and we wanted to give it some time, perhaps incorporating changes from Project Lambda in SE 8, before committing to something (there's a lot of overlap between anonymous classes and lambda expressions).  Some of these ideas:

- Perhaps we will want to expand the set of denotable types.

- There may be other reasons in Lambda to infer type arguments that are restricted to a denotable subset of types, and we'll want one cohesive approach for this.

- With lambda expressions, we infer type arguments from the expression's method signature, not just its context.  Perhaps we could do something similar with anonymous classes.

So why not do something simple now and then tweak it later?  Because inference changes (even when they're "improvements") are typically source incompatible.  Once we've committed to a particular strategy, it is hard to change it later.

Also, Remi's answer is worth repeating: most of these use cases (though not all of yours -- LazyMap appears to be a class, for example) will probably be re-expressible as lambda expressions in SE 8.  In that case, we'll infer not just the type arguments, but the interface name and the method signature as well.  And give you better performance to boot.

?Dan

On Jun 23, 2011, at 6:56 PM, Derek Foster wrote:

> Hi, folks.
> 
> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
> 
> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
> 
>   private final List<Integer> foo = new ArrayList<>();
> 
> and in anonymous class declarations such as:
> 
>   public static final Callable<Integer> TASK = new Callable<>() {
>      public Integer call() {
>          return doSomething();
>      } 
>   };
> 
> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
> 
> I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.) 
> 
> In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:
> 
> class MyNiftyClass {
> public static final Comparator<MyNiftyClass> FORWARD = new Comparator<MyNiftyClass>() {
>    @Override
>    public int compare(MyNiftyClass first, MyNiftyClass second) {
>        ... comparator logic goes here ...
>    }
> };
> public static final Comparator<MyNiftyClass> BACKWARD = new Comparator<MyNiftyClass>() {
>    @Override
>    public int compare(MyNiftyClass first, MyNiftyClass second) {
>        return FORWARD.compare(second, first);
>    }
> };
> ...
> }
> 
> 
> In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:
> 
> // One member of a large hierarchy of items that have a similar structure
> class NativeColorWrapper extends NativeObject {
> 
>   // A public factory for creating instances of NativeColorWrapper by wrapping a native
>   // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
>   // is used for all instance creation.
>   public static final NativeFactory<INativeUnboundContext, NativeColorWrapper> FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
>       @Override
>       public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
>           return new NativeColorWrapper(context, nativePointer);
>       }
>   };
> 
>   // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
>   // There are multiple instances of these caches, with various differing generic
>   // parameter types depending on the data to be cached.
>   private final LazyMap<NativeIdentifier, SortedSet<NativeItem>> _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
>       protected SortedSet<NativeItem> fetch(NativeIdentifier binding) {
>           long[] nativePointers = someNativeMethod(binding.toString());
>           return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
>       }
>   };
>   ...
> }
> 
> A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.
> 
> This is backed up to some degree by bug reports such as this one:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753
> 
> Which states:
> 
> "
> In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.
> 
> There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
> "
> 
> It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:
> 
> The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")
> 
> Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.
> 
> Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)
> 
> Thanks for any information.
> 
> Derek
> 
> 



From joe.darcy at oracle.com  Fri Jun 24 11:37:09 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 24 Jun 2011 11:37:09 -0700
Subject: Diamond operator and anonymous classes
In-Reply-To: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
References: <30453801.1308880590286.JavaMail.root@wamui-junio.atl.sa.earthlink.net>
Message-ID: <4E04D955.6000903@oracle.com>

Hello Derek,

First, thank you for relaying your experiences using the Coin features 
on actual code.  This is helpful input to possible future Coin 
refinements in JDK 8.

Derek Foster wrote:
> Hi, folks.
>
> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
>
> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
>
>    private final List<Integer> foo = new ArrayList<>();
>
> and in anonymous class declarations such as:
>
>    public static final Callable<Integer> TASK = new Callable<>() {
>       public Integer call() {
>           return doSomething();
>       } 
>    };
>
> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
>   

At the start of March, I posted "Project Coin Documentation v0.83" [1] 
and informed the coin-dev list of this document [2] (as well as blogged 
about it [3]); that document states in the discussion section for diamond:

"Using diamond with anonymous inner classes is not supported since doing 
so in general would require extensions to the class file signature 
attribute to represent non-denotable types, a de facto JVM change."

and there is a further addendum

"(Note that 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.)"

As David Holmes has already quoted, there is a fuller discussion of 
diamond and anonymous inner class decision in the subsequent version of 
the Project Coin documentation [4] and Dan Smith has replied with more 
information about future evolution possibilities.

Since David and Dan have addressed the technical points, I'd like to to 
discuss the communications issues around Project Coin and JSR 334.

I understand that some people are frustrated that indications were made 
that the JSR 334 expert group archives were going to be public and, to 
date, they have not been.  While this is unfortunate,  I don't think 
this renders the decisions and progress of Project Coin impossible to 
follow.  Major expert group decisions have corresponding threads on 
coin-dev, e.g.:

* "Update on JSR 334 Expert Group activities," January 21, 2011
    http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002972.html

* "How to terminate resources in try-with-resources"
    http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/003054.html

* "Specification update: diamond and explicit generic constructor 
argument no longer supported"
    http://mail.openjdk.java.net/pipermail/coin-dev/2011-May/003250.html

and discussions started on coin-dev have directly influenced the outcome 
of the JSR and the reference implementation, including but not limited to:

* diamond and raw types bug
    
http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003067.html

* null handling of try-with-resources
    http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002960.html
    
http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003076.html

I have striven to make the Project Coin documentation drops, and the 
similar materials posted for the JSR 334 milestones, stand-alone 
documents that contain the rationale for the changes.  From a quick 
scan, roughly one third of of the v0.9375 document is discussion as 
opposed to specification.

I have at times been disappointed in the coin-dev response to these 
documents and threads.  For example, for a full week after the v0.83 
document was posted, there was exactly zero response on coin-dev.  When 
prompted with a follow-up message seven days later, the primary reaction 
was on a minor syntax point.  No one is obliged to read these documents 
or respond to them.  However, in my own estimation there has not been a 
shortage of information made available about Coin and its progress over 
time in various venues and issues raised on coin-dev continue to be 
responded to promptly by myself and others.

-Joe

[1] 
http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
[2] http://mail.openjdk.java.net/pipermail/coin-dev/2011-March/003124.html
[3] http://blogs.oracle.com/darcy/entry/project_coin_developer_preview
[4] 
http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html



From joe.darcy at oracle.com  Fri Jun 24 11:40:56 2011
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 24 Jun 2011 11:40:56 -0700
Subject: IDE support for Project Coin
In-Reply-To: <4DC47C0E.9040200@oracle.com>
References: <4DB0DDA2.2090107@oracle.com> <4DC47C0E.9040200@oracle.com>
Message-ID: <4E04DA38.1070506@oracle.com>

Update on the Eclipse support:
http://thecoderlounge.blogspot.com/2011/06/java-7-support-in-eclipse-jdt-beta.html

-Joe

Joe Darcy wrote:
> Additional information on planned Eclipse support for JDK 7:
> http://thecoderlounge.blogspot.com/2011/05/eclipse-jdt-and-java-7.html
>
> -Joe
>
> Joe Darcy wrote:
>> FYI, all of NetBeans, IntelliJ, and Eclipse have some level of 
>> support in progress for Project Coin's language features.
>>
>> The recently released NetBeans 7.0 [1]  has support for all the Coin 
>> features.  As explained in its release notes [2], beyond just 
>> recognizing the features in the editor NetBeans 7.0 provides 
>> auto-completion to diamond and gives hints to apply the new features 
>> to existing code.
>>
>> As previously announced for IntelliJ IDEA [3], the builds of IDEA 
>> 10.5 EAP (early access program) [4] provide similar quickfix support.
>>
>> Finally, an Eclipse branch [5] is hosting their efforts to support 
>> Project Coin.
>>
>> As JSR 334 is not quite done yet [6], I'd expect the IDEs to be 
>> updated after JSR 334 is completed to account for any specification 
>> changes made in the interim.
>>
>> Happy hacking,
>>
>> -Joe
>>
>> [1] http://netbeans.org/community/releases/70/
>> [2] http://wiki.netbeans.org/NewAndNoteworthyNB70#JDK7_support
>> [3] 
>> http://blogs.jetbrains.com/idea/2011/02/announcing-intellij-idea-105-with-full-java-7-support/ 
>>
>> [4] http://confluence.jetbrains.net/display/IDEADEV/IDEA+10.5+EAP
>> [5] http://wiki.eclipse.org/JDT_Core/Java7
>> [6] http://blogs.sun.com/darcy/entry/project_coin_jsr_334_pr
>>
>>
>>   
>



From joe.darcy at oracle.com  Fri Jun 24 15:37:23 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Fri, 24 Jun 2011 15:37:23 -0700
Subject: FYI, JSR 334 has reached proposed final draft
Message-ID: <4E0511A3.50502@oracle.com>

Hello.

FYI, the proposed final draft specification of JSR 334 can now be 
downloaded from:
http://jcp.org/aboutJava/communityprocess/pfd/jsr334/index.html

-Joe


From neal at gafter.com  Fri Jun 24 23:05:53 2011
From: neal at gafter.com (Neal Gafter)
Date: Fri, 24 Jun 2011 23:05:53 -0700
Subject: FYI, JSR 334 has reached proposed final draft
In-Reply-To: <4E0511A3.50502@oracle.com>
References: <4E0511A3.50502@oracle.com>
Message-ID: <BANLkTintwmy5MbO6dCSE=+CGBHZ=SqLifg@mail.gmail.com>

One longstanding concern with the try-with-resource statement was the
software engineering implications of attempting to handle suppressed
exceptions - compared to other proposed mechanisms to handle them, there is
no obvious and scalable way with the currently proposed language construct
to organize programs to handle them (the only proposed code organization
techniques do not scale).  The response to this concern (since early coin
days) from the proponents of the current specification was we should
prototype the construct and see what patterns develop in code that uses the
construct, and then adjust the specification based on that experience.

That experience is necessary because it might not be possible to compatibly
address problems that experience may expose.  The developers associated with
project coin have no doubt written lots of new code using the feature and
reported their experience attempting to handle suppressed exceptions to the
jsr 224 mailing list, but we listeners on the coin list have unfortunately
not gained the benefit of that discussion.  The discussion shown publicly on
this list is insufficient in my mind to support an assumption that the
current mechanism has passed scrutiny from this point of view.  Therefore I
would ask the jsr 244 members to please summarize the relevant experience.

Cheers,
Neal

On Fri, Jun 24, 2011 at 3:37 PM, <joe.darcy at oracle.com> wrote:

> Hello.
>
> FYI, the proposed final draft specification of JSR 334 can now be
> downloaded from:
> http://jcp.org/aboutJava/communityprocess/pfd/jsr334/index.html
>
> -Joe
>
>


From vapor1 at teleport.com  Fri Jun 24 23:10:18 2011
From: vapor1 at teleport.com (Derek Foster)
Date: Fri, 24 Jun 2011 23:10:18 -0700 (GMT-07:00)
Subject: Diamond operator and anonymous classes
Message-ID: <278462.1308982218631.JavaMail.root@wamui-cynical.atl.sa.earthlink.net>

Hi, David.

Thanks for the reply.

I was already aware of the document you are referencing. I read it when it was first posted to this list. Unfortunately, the document doesn't really describe the middle ground between "we can't do it for non-denotable types" and "we're not going to do it for any anonymous types at all in this release", or why the current approach was selected over others such as the one I suggested.

In any case, the main point of my email was to point out that I had been repeatedly encountering this issue as a "pain point" in use of JDK7. Therefore, if the current approach was based in part on "we don't think that users are going to hit this very often", I wanted to present some evidence otherwise.

Derek

-----Original Message-----
>From: David Holmes <David.Holmes at oracle.com>
>Sent: Jun 24, 2011 1:03 AM
>To: Derek Foster <vapor1 at teleport.com>
>Cc: Project Coin <coin-dev at openjdk.java.net>
>Subject: Re: Diamond operator and anonymous classes
>
>Derek,
>
>This has been raised a couple of time already. The reasoning is given in 
>the current Coin documentation (not sure if there's an official version 
>yet):
>
>http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html
>
>where it states:
>
>"Internally, a Java compiler operates over a richer set of types than 
>those that can be written down explicitly in a Java program. The 
>compiler-internal types which cannot be written in a Java program are 
>called non-denotable types. Non-denotable types can occur as the result 
>of the inference used by diamond. Therefore, using diamond with 
>anonymous inner classes is not supported since doing so in general would 
>require extensions to the class file signature attribute to represent 
>non-denotable types, a de facto JVM change. It is feasible that future 
>platform versions could allow use of diamond when creating an anonymous 
>inner class as long as the inferred type was denotable. "
>
>As you can see the door is open for relaxing the current rules in the 
>future.
>
>Cheers,
>David Holmes
>
>Derek Foster said the following on 06/24/11 11:56:
>> Hi, folks.
>> 
>> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
>> 
>> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
>> 
>>    private final List<Integer> foo = new ArrayList<>();
>> 
>> and in anonymous class declarations such as:
>> 
>>    public static final Callable<Integer> TASK = new Callable<>() {
>>       public Integer call() {
>>           return doSomething();
>>       } 
>>    };
>> 
>> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
>> 
>> I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.) 
>> 
>> In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:
>> 
>> class MyNiftyClass {
>> public static final Comparator<MyNiftyClass> FORWARD = new Comparator<MyNiftyClass>() {
>>     @Override
>>     public int compare(MyNiftyClass first, MyNiftyClass second) {
>>         ... comparator logic goes here ...
>>     }
>> };
>> public static final Comparator<MyNiftyClass> BACKWARD = new Comparator<MyNiftyClass>() {
>>     @Override
>>     public int compare(MyNiftyClass first, MyNiftyClass second) {
>>         return FORWARD.compare(second, first);
>>     }
>> };
>> ...
>> }
>> 
>> 
>> In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:
>> 
>> // One member of a large hierarchy of items that have a similar structure
>> class NativeColorWrapper extends NativeObject {
>> 
>>    // A public factory for creating instances of NativeColorWrapper by wrapping a native
>>    // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
>>    // is used for all instance creation.
>>    public static final NativeFactory<INativeUnboundContext, NativeColorWrapper> FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
>>        @Override
>>        public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
>>            return new NativeColorWrapper(context, nativePointer);
>>        }
>>    };
>> 
>>    // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
>>    // There are multiple instances of these caches, with various differing generic
>>    // parameter types depending on the data to be cached.
>>    private final LazyMap<NativeIdentifier, SortedSet<NativeItem>> _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
>>        protected SortedSet<NativeItem> fetch(NativeIdentifier binding) {
>>            long[] nativePointers = someNativeMethod(binding.toString());
>>            return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
>>        }
>>    };
>>    ...
>> }
>> 
>> A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.
>> 
>> This is backed up to some degree by bug reports such as this one:
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753
>> 
>> Which states:
>> 
>> "
>> In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.
>> 
>> There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
>> "
>> 
>> It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:
>> 
>> The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")
>> 
>> Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.
>> 
>> Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)
>> 
>> Thanks for any information.
>> 
>> Derek
>> 
>> 



From vapor1 at teleport.com  Fri Jun 24 23:22:22 2011
From: vapor1 at teleport.com (Derek Foster)
Date: Fri, 24 Jun 2011 23:22:22 -0700 (GMT-07:00)
Subject: Diamond operator and anonymous classes
Message-ID: <20183438.1308982942264.JavaMail.root@wamui-cynical.atl.sa.earthlink.net>

Hi, R?mi.

Thanks for your reply.

I've been reading the traffic on the lambda-dev list since its beginning, so yes, I am aware that the specific examples I listed can be rewritten as lambdas. However, that doesn't address the general case. For instance, although the specific example that I gave of a factory class happens to have a simple one-liner constructor call as the method body, that's not necessarily true in the general case of the code I am dealing with. Some of the factories are moderately complex. If, for instance, an anonymous factory instance needs to override more than one method from its base class (which is an abstract class, by the way, not an interface) in order to accomplish its task, or needs to declare other worker methods to be called from its main factory method, a lambda won't suffice. Similarly for the LazyMap abstract class. I will grant that I have a hard time imagining an instance of Comparable which couldn't easily be a lambda, but I'm sure they exist in someone's code.

So, you are right that lambdas would be an attractive option in much of this code, but they aren't sufficient to solve all of the issues I am raising.

Derek

-----Original Message-----
>From: R?mi Forax <forax at univ-mlv.fr>
>Sent: Jun 24, 2011 1:19 AM
>To: coin-dev at openjdk.java.net
>Subject: Re: Diamond operator and anonymous classes
>
>Your examples are lambdas, Java 8 will introduce a syntax for that.
>By example,
>
>public static final Comparator<MyNiftyClass>  BACKWARD = new Comparator<MyNiftyClass>() {
>     @Override
>     public int compare(MyNiftyClass first, MyNiftyClass second) {
>         return FORWARD.compare(second, first);
>     }
>};
>
>can be rewritten it to:
>
>public static final Comparator<MyNiftyClass>  BACKWARD =
>    #{ first, second ->  FORWARD.compare(second, first); };
>
>or a similar syntax (this part is not frozen yet).
>
>R?mi
>
>
>On 06/24/2011 10:03 AM, David Holmes wrote:
>> Derek,
>>
>> This has been raised a couple of time already. The reasoning is given in
>> the current Coin documentation (not sure if there's an official version
>> yet):
>>
>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.9375.html
>>
>> where it states:
>>
>> "Internally, a Java compiler operates over a richer set of types than
>> those that can be written down explicitly in a Java program. The
>> compiler-internal types which cannot be written in a Java program are
>> called non-denotable types. Non-denotable types can occur as the result
>> of the inference used by diamond. Therefore, using diamond with
>> anonymous inner classes is not supported since doing so in general would
>> require extensions to the class file signature attribute to represent
>> non-denotable types, a de facto JVM change. It is feasible that future
>> platform versions could allow use of diamond when creating an anonymous
>> inner class as long as the inferred type was denotable. "
>>
>> As you can see the door is open for relaxing the current rules in the
>> future.
>>
>> Cheers,
>> David Holmes
>>
>> Derek Foster said the following on 06/24/11 11:56:
>>> Hi, folks.
>>>
>>> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
>>>
>>> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
>>>
>>>     private final List<Integer>  foo = new ArrayList<>();
>>>
>>> and in anonymous class declarations such as:
>>>
>>>     public static final Callable<Integer>  TASK = new Callable<>() {
>>>        public Integer call() {
>>>            return doSomething();
>>>        }
>>>     };
>>>
>>> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
>>>
>>> I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.)
>>>
>>> In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:
>>>
>>> class MyNiftyClass {
>>> public static final Comparator<MyNiftyClass>  FORWARD = new Comparator<MyNiftyClass>() {
>>>      @Override
>>>      public int compare(MyNiftyClass first, MyNiftyClass second) {
>>>          ... comparator logic goes here ...
>>>      }
>>> };
>>> public static final Comparator<MyNiftyClass>  BACKWARD = new Comparator<MyNiftyClass>() {
>>>      @Override
>>>      public int compare(MyNiftyClass first, MyNiftyClass second) {
>>>          return FORWARD.compare(second, first);
>>>      }
>>> };
>>> ...
>>> }
>>>
>>>
>>> In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:
>>>
>>> // One member of a large hierarchy of items that have a similar structure
>>> class NativeColorWrapper extends NativeObject {
>>>
>>>     // A public factory for creating instances of NativeColorWrapper by wrapping a native
>>>     // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
>>>     // is used for all instance creation.
>>>     public static final NativeFactory<INativeUnboundContext, NativeColorWrapper>  FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
>>>         @Override
>>>         public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
>>>             return new NativeColorWrapper(context, nativePointer);
>>>         }
>>>     };
>>>
>>>     // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
>>>     // There are multiple instances of these caches, with various differing generic
>>>     // parameter types depending on the data to be cached.
>>>     private final LazyMap<NativeIdentifier, SortedSet<NativeItem>>  _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
>>>         protected SortedSet<NativeItem>  fetch(NativeIdentifier binding) {
>>>             long[] nativePointers = someNativeMethod(binding.toString());
>>>             return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
>>>         }
>>>     };
>>>     ...
>>> }
>>>
>>> A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.
>>>
>>> This is backed up to some degree by bug reports such as this one:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753
>>>
>>> Which states:
>>>
>>> "
>>> In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.
>>>
>>> There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
>>> "
>>>
>>> It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:
>>>
>>> The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")
>>>
>>> Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.
>>>
>>> Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)
>>>
>>> Thanks for any information.
>>>
>>> Derek
>>>
>>>
>
>



From vapor1 at teleport.com  Sat Jun 25 00:07:50 2011
From: vapor1 at teleport.com (Derek Foster)
Date: Sat, 25 Jun 2011 03:07:50 -0400 (EDT)
Subject: Diamond operator and anonymous classes
Message-ID: <17033812.1308985670830.JavaMail.root@wamui-cynical.atl.sa.earthlink.net>

Hi, Dan.

Thanks for your reply. This is without a doubt the most informative writing I have seen on this subject.

>The fundamental problem is that inference in this case is more than just
>inference of type arguments for a constructor call -- these are type
>arguments for an 'extends' clause, which impacts inheritance/overloading
>and the generated class file.

I can see how it would affect inheritance/overloading, but I must confess I don't understand how it would affect the generated class file. It seems to me that erasure would eliminate the impact of the generic parameters on the class file. What am I missing here? In any case, it seems to me that since generic resolution and diamondification is done at compile time, that the class file for a diamond operator should end up being the same as for the equivalent non-diamond declaration. Could you please clarify this?

I am a bit unclear on how non-denotable types raise more of an issue for anonymous types in the context of the diamond operator than they already do without the diamond operator in declarations such as the following:

	class Q<R> {Q(Class<R> r) {}}
	<T extends java.util.Date & Closeable> Q<T> getAnon(Class<T> type) {
		final Q<T> q = new Q<T>(type) {
		};
		return q;
	}
 
which seems to be legal Java code as far as I can tell. (At least, Eclipse doesn't complain.) If I were to use "new Q<>()" in the above instead of "new Q<T>()", shouldn't the generated class file be the same?

>Motivating the deferral is that there were a few different ideas about how to handle this,
>and we wanted to give it some time, perhaps incorporating changes from Project Lambda in
>SE 8, before committing to something (there's a lot of overlap between anonymous classes
>and lambda expressions).  Some of these ideas:
>
>- Perhaps we will want to expand the set of denotable types.
>
>- There may be other reasons in Lambda to infer type arguments that are
>  restricted to a denotable subset of types, and we'll want one cohesive approach for this.
>
>- With lambda expressions, we infer type arguments from the expression's
>  method signature, not just its context.  Perhaps we could do something similar
>  with anonymous classes.
>
>So why not do something simple now and then tweak it later?  Because inference
>changes (even when they're "improvements") are typically source incompatible.  Once
>we've committed to a particular strategy, it is hard to change it later.

Thanks again. This is a much clearer explanation of the reasoning behind the decision than I have seen anywhere else.

>Also, Remi's answer is worth repeating: most of these use cases (though not all of
>yours -- LazyMap appears to be a class, for example) will probably be re-expressible
>as lambda expressions in SE 8.  In that case, we'll infer not just the type
>arguments, but the interface name and the method signature as well.  And give
>you better performance to boot.

As you can see from my reply to Remi, I agree that lamdas would help, and I'm very much looking forwards to using them, but they don't completely address the problems I am trying to solve.

Derek

>
>?Dan
>
>On Jun 23, 2011, at 6:56 PM, Derek Foster wrote:
>
>> Hi, folks.
>> 
>> I've been experimenting with applying the JDK 7 language additions to some code bases of mine, and anticipating such changes to my employer's code base at such time as we can upgrade to JDK 7. In most cases, this has gone quite well. However, I have run into one issue that has been rather annoying in some places. This has to do with the diamond operator.
>> 
>> As originally proposed and reviewed on the Project Coin mailing list, the diamond operator could be used in both ordinary instance declarations, like:
>> 
>>   private final List<Integer> foo = new ArrayList<>();
>> 
>> and in anonymous class declarations such as:
>> 
>>   public static final Callable<Integer> TASK = new Callable<>() {
>>      public Integer call() {
>>          return doSomething();
>>      } 
>>   };
>> 
>> However, a later decision (by the Expert Group? or someone else?) declared that there were technical problems in implementing this for anonymous classes, and that support for using the diamond operator in anonymous classes would be dropped. (Unfortunately, I am unable to go review the expert group's discussions to determine what the detailed motivations were for making this change, since the expert group's discussions are apparently not public. I am a bit frustrated by the lack of visibility for this change and its motivations.)
>> 
>> I originally thought that restricting use of the diamond operator for anonymous classes would be a minor, rare annoyance. This issue was in fact one of the first issues that I encountered when trying to move an existing codebase to use JDK 7 constructs. (I told IntelliJ Idea to globally convert all diamondable instances of code in my project to use the diamond operator. It did so, and then my code wouldn't compile. I then found that diamond was disallowed for anonymous classes, informed JetBrains, and they fixed Idea not to suggest an autofix in those cases.) 
>> 
>> In that case, a very small project, I encountered problems with this kind of code, which I would have liked to use the diamond operator for but couldn't:
>> 
>> class MyNiftyClass {
>> public static final Comparator<MyNiftyClass> FORWARD = new Comparator<MyNiftyClass>() {
>>    @Override
>>    public int compare(MyNiftyClass first, MyNiftyClass second) {
>>        ... comparator logic goes here ...
>>    }
>> };
>> public static final Comparator<MyNiftyClass> BACKWARD = new Comparator<MyNiftyClass>() {
>>    @Override
>>    public int compare(MyNiftyClass first, MyNiftyClass second) {
>>        return FORWARD.compare(second, first);
>>    }
>> };
>> ...
>> }
>> 
>> 
>> In my employer's codebase, however, I am encountering MANY more instances of this problem, due to the architecture of the framework it is using. Typical (paraphrased) code looks like this:
>> 
>> // One member of a large hierarchy of items that have a similar structure
>> class NativeColorWrapper extends NativeObject {
>> 
>>   // A public factory for creating instances of NativeColorWrapper by wrapping a native
>>   // pointer. Every subtype of NativeObject has one of these, named FACTORY, which
>>   // is used for all instance creation.
>>   public static final NativeFactory<INativeUnboundContext, NativeColorWrapper> FACTORY = new NativeFactory<INativeUnboundContext, NativeColorWrapper>() {
>>       @Override
>>       public NativeColorWrapper create(INativeUnboundContext context, long nativePointer) {
>>           return new NativeColorWrapper(context, nativePointer);
>>       }
>>   };
>> 
>>   // An internal cache, in this case for lazily binding identifiers to sorted lists of items.
>>   // There are multiple instances of these caches, with various differing generic
>>   // parameter types depending on the data to be cached.
>>   private final LazyMap<NativeIdentifier, SortedSet<NativeItem>> _itemCache = new LazyMap<NativeIdentifier, SortedSet<NativeItem>>() {
>>       protected SortedSet<NativeItem> fetch(NativeIdentifier binding) {
>>           long[] nativePointers = someNativeMethod(binding.toString());
>>           return new TreeSet<NativeItem>(wrapItems(NativeItem.FACTORY, nativePointers));
>>       }
>>   };
>>   ...
>> }
>> 
>> A few months ago, Joe Darcy posted a message on the Project Coin mailing list suggesting (if I understood it correctly) that the reason for dropping support for anonymous classes was due to problems with potential use of non-denotatable types as generic type parameters, which would require a change to the class file format if it were to be supported.
>> 
>> This is backed up to some degree by bug reports such as this one:
>> 
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6894753
>> 
>> Which states:
>> 
>> "
>> In all failing cases we have that the parameter type for such instantiated type contains an intersection type. Since there's no AST representation for intersection types, javac fails to create an AST node for the inferred type, and this result in the crashes described in this report.
>> 
>> There are two ways for fixing this problem. One is to add AST internal support for intersection types - so that we can keep javac happy. Another is to change the attribution scheme for inner classes (but I don't see this as a feasible approach).
>> "
>> 
>> It seems to me that the current "solution" of completely disallowing use of diamond with anonymous classes is an overreaction to the problem that has so far been described. It disallows problematic constructs, but it also disallows non-problematic, useful constructs. I would like to suggest a third option from the two that are listed in the above bug report:
>> 
>> The diamond operator would be allowed for anonymous classes if and only if none of the generic type parameters which are inferred would be non-denotable types, and would be treated as a compile-time error otherwise. ("Error: Can't use diamond operator with anonymous class when non-denotable types would be inferred.")
>> 
>> Use of the diamond operator would help readability quite a bit in the examples I have shown above. Many of the declarations could fit on one line, while they currently cannot. I am not aware of any technical reason why this couldn't be allowed (although I'm sure some list participant will swiftly inform me otherwise if I am wrong. :-) ) It appears to me that allowing the diamond operator for anonymous classes with only denotatable types would allow me to use the diamond operator in all of the cases that I actually care about, while still avoiding changes to the class file format and the problems suggested in the above bug report.
>> 
>> Could something like this be put into JDK 8? (I am assuming it's too late for JDK 7, but I would be thrilled to be wrong about this.)
>> 
>> Thanks for any information.
>> 
>> Derek
>> 
>> 
>



From mike.duigou at oracle.com  Sat Jun 25 00:08:15 2011
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Sat, 25 Jun 2011 00:08:15 -0700 (PDT)
Subject: Auto Reply: coin-dev Digest, Vol 29, Issue 9
Message-ID: <e72990ea-d140-431b-ba33-bc30c08ff2c0@default>

I am on vacation until July 11, 2011. For urgent matters contact my manager frances.ho at oracle.com or for very urgent matters call my cell phone at five one zero nine one eight five seven two zero.


From daniel.smith at oracle.com  Sat Jun 25 08:48:28 2011
From: daniel.smith at oracle.com (Dan Smith)
Date: Sat, 25 Jun 2011 08:48:28 -0700
Subject: Diamond operator and anonymous classes
In-Reply-To: <17033812.1308985670830.JavaMail.root@wamui-cynical.atl.sa.earthlink.net>
References: <17033812.1308985670830.JavaMail.root@wamui-cynical.atl.sa.earthlink.net>
Message-ID: <6CA3C2DF-5681-4097-A81B-E4C53A32C6A9@oracle.com>

On Jun 25, 2011, at 12:07 AM, Derek Foster wrote:

> Hi, Dan.
> 
> Thanks for your reply. This is without a doubt the most informative writing I have seen on this subject.
> 
>> The fundamental problem is that inference in this case is more than just
>> inference of type arguments for a constructor call -- these are type
>> arguments for an 'extends' clause, which impacts inheritance/overloading
>> and the generated class file.
> 
> I can see how it would affect inheritance/overloading, but I must confess I don't understand how it would affect the generated class file. It seems to me that erasure would eliminate the impact of the generic parameters on the class file. What am I missing here? In any case, it seems to me that since generic resolution and diamondification is done at compile time, that the class file for a diamond operator should end up being the same as for the equivalent non-diamond declaration. Could you please clarify this?
> 
> I am a bit unclear on how non-denotable types raise more of an issue for anonymous types in the context of the diamond operator than they already do without the diamond operator in declarations such as the following:
> 
> 	class Q<R> {Q(Class<R> r) {}}
> 	<T extends java.util.Date & Closeable> Q<T> getAnon(Class<T> type) {
> 		final Q<T> q = new Q<T>(type) {
> 		};
> 		return q;
> 	}
> 
> which seems to be legal Java code as far as I can tell. (At least, Eclipse doesn't complain.) If I were to use "new Q<>()" in the above instead of "new Q<T>()", shouldn't the generated class file be the same?

See section 4.4.4, here:

<http://java.sun.com/docs/books/jvms/second_edition/ClassFileFormat-Java5.pdf>

The concern over "denotable types" is with types that cannot be denoted with a FieldTypeSignature.  This includes intersection types and capture variables (standard type variables, as in your example, _are_ denotable).

Example:

// Assume LiteralList has a constructor like Arrays.asList
// Inferred type argument is Number & Comparable<? extends ...>
method(new LiteralList<>(1, 2.0) { ... });

Of course this is atypical, and one could envision carving out such special cases as unsupported, rather than throwing out all anonymous classes.  But see my previous comments about why we felt that "no anonymous classes" was the right place to draw the line for now.

?Dan



From neal at gafter.com  Wed Jun 29 07:11:58 2011
From: neal at gafter.com (Neal Gafter)
Date: Wed, 29 Jun 2011 07:11:58 -0700
Subject: FYI, JSR 334 has reached proposed final draft
In-Reply-To: <BANLkTintwmy5MbO6dCSE=+CGBHZ=SqLifg@mail.gmail.com>
References: <4E0511A3.50502@oracle.com>
	<BANLkTintwmy5MbO6dCSE=+CGBHZ=SqLifg@mail.gmail.com>
Message-ID: <BANLkTikPogXt5qYkrQNwa7-X0qFdnnt-Xg@mail.gmail.com>

<crickets>

</crickets>

I read the lack of response as "we really just don't care.".  Which
says to me that getting the release out on schedule is seen as more
important than having confidence in the language changes going into
the release.

Disappointing.

On Friday, June 24, 2011, Neal Gafter <neal at gafter.com> wrote:
> One longstanding concern with the try-with-resource statement was the software engineering implications of attempting to handle suppressed exceptions - compared to other proposed mechanisms to handle them, there is no obvious and scalable way with the currently proposed language construct to organize programs to handle them (the only proposed code organization techniques do not scale).? The response to this concern (since early coin days) from the proponents of the current specification was we should prototype the construct and see what patterns develop in code that uses the construct, and then adjust the specification based on that experience.
>
> That experience is necessary because it might not be possible to compatibly address problems that experience may expose.? The developers associated with project coin have no doubt written lots of new code using the feature and reported their experience attempting to handle suppressed exceptions to the jsr 224 mailing list, but we listeners on the coin list have unfortunately not gained the benefit of that discussion.? The discussion shown publicly on this list is insufficient in my mind to support an assumption that the current mechanism has passed scrutiny from this point of view.? Therefore I would ask the jsr 244 members to please summarize the relevant experience.
>
> Cheers,
> Neal
>
> On Fri, Jun 24, 2011 at 3:37 PM,  <joe.darcy at oracle.com> wrote:
>
> Hello.
>
> FYI, the proposed final draft specification of JSR 334 can now be
> downloaded from:
> http://jcp.org/aboutJava/communityprocess/pfd/jsr334/index.html
>
> -Joe
>
>
>


From neal at gafter.com  Wed Jun 29 07:17:09 2011
From: neal at gafter.com (Neal Gafter)
Date: Wed, 29 Jun 2011 07:17:09 -0700
Subject: FYI, JSR 334 has reached proposed final draft
In-Reply-To: <BANLkTikPogXt5qYkrQNwa7-X0qFdnnt-Xg@mail.gmail.com>
References: <4E0511A3.50502@oracle.com>
	<BANLkTintwmy5MbO6dCSE=+CGBHZ=SqLifg@mail.gmail.com>
	<BANLkTikPogXt5qYkrQNwa7-X0qFdnnt-Xg@mail.gmail.com>
Message-ID: <BANLkTimDAgkcDrE731mWZm+f2+ZYwJV=nw@mail.gmail.com>

Either that or the openjdk.java.net domain was down.  (it was down)

On Wednesday, June 29, 2011, Neal Gafter <neal at gafter.com> wrote:
> <crickets>
>
> </crickets>
>
> I read the lack of response as "we really just don't care.". ?Which
> says to me that getting the release out on schedule is seen as more
> important than having confidence in the language changes going into
> the release.
>
> Disappointing.
>
> On Friday, June 24, 2011, Neal Gafter <neal at gafter.com> wrote:
>> One longstanding concern with the try-with-resource statement was the software engineering implications of attempting to handle suppressed exceptions - compared to other proposed mechanisms to handle them, there is no obvious and scalable way with the currently proposed language construct to organize programs to handle them (the only proposed code organization techniques do not scale).? The response to this concern (since early coin days) from the proponents of the current specification was we should prototype the construct and see what patterns develop in code that uses the construct, and then adjust the specification based on that experience.
>>
>> That experience is necessary because it might not be possible to compatibly address problems that experience may expose.? The developers associated with project coin have no doubt written lots of new code using the feature and reported their experience attempting to handle suppressed exceptions to the jsr 224 mailing list, but we listeners on the coin list have unfortunately not gained the benefit of that discussion.? The discussion shown publicly on this list is insufficient in my mind to support an assumption that the current mechanism has passed scrutiny from this point of view.? Therefore I would ask the jsr 244 members to please summarize the relevant experience.
>>
>> Cheers,
>> Neal
>>
>> On Fri, Jun 24, 2011 at 3:37 PM, ?<joe.darcy at oracle.com> wrote:
>>
>> Hello.
>>
>> FYI, the proposed final draft specification of JSR 334 can now be
>> downloaded from:
>> http://jcp.org/aboutJava/communityprocess/pfd/jsr334/index.html
>>
>> -Joe
>>
>>
>>
>


From joe.darcy at oracle.com  Wed Jun 29 19:53:21 2011
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 29 Jun 2011 19:53:21 -0700
Subject: FYI, JSR 334 has reached proposed final draft
In-Reply-To: <BANLkTimDAgkcDrE731mWZm+f2+ZYwJV=nw@mail.gmail.com>
References: <4E0511A3.50502@oracle.com>	<BANLkTintwmy5MbO6dCSE=+CGBHZ=SqLifg@mail.gmail.com>	<BANLkTikPogXt5qYkrQNwa7-X0qFdnnt-Xg@mail.gmail.com>
	<BANLkTimDAgkcDrE731mWZm+f2+ZYwJV=nw@mail.gmail.com>
Message-ID: <4E0BE521.2090907@oracle.com>

Neal,

The coin-dev mailing list is not a venue with a service level agreement 
promising a two business day or less turn-around-time to requests of 
arbitrary size.

There has been bi-directional communication between the coin-dev 
community and the JSR 334 expert group since the expert group came into 
existence.  This communication has taken place not only because there is 
overlap in the membership of those bodies, but also because I've sent 
regular updates to coin-dev about changes in the specification and 
implementation and also made sure that the expert group considered 
issues raised on coin-dev.  For example, the changes to the null 
handling of try-with-resources earlier this year [1] came about after an 
investigation sparked by comments Remi sent to coin-dev [2].  Sometimes 
issues can only get addressed months after they are raised, such as the 
interplay between try-with-resources and InterruptedException. [3]

In the past on coin-dev, you're alluded to a set of detailed comments 
you have about the JSR 334 specification that you are choosing to 
withhold because the expert group archives are not publicly readable.  
While I respect your decision and the reasons for it, I am disappointed 
that Project Coin will not have time to benefit from your feedback 
before JSR 334 concludes and JDK 7 ships.

Regards,

-Joe

[1] 
http://mail.openjdk.java.net/pipermail/coin-dev/2011-February/003076.html
[2] http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002960.html
[3] http://mail.openjdk.java.net/pipermail/coin-dev/2011-March/003161.html

On 6/29/2011 7:17 AM, Neal Gafter wrote:
> Either that or the openjdk.java.net domain was down.  (it was down)
>
> On Wednesday, June 29, 2011, Neal Gafter <neal at gafter.com> wrote:
>   
>> <crickets>
>>
>> </crickets>
>>
>> I read the lack of response as "we really just don't care.".  Which
>> says to me that getting the release out on schedule is seen as more
>> important than having confidence in the language changes going into
>> the release.
>>
>> Disappointing.
>>
>> On Friday, June 24, 2011, Neal Gafter <neal at gafter.com> wrote:
>>     
>>> One longstanding concern with the try-with-resource statement was the software engineering implications of attempting to handle suppressed exceptions - compared to other proposed mechanisms to handle them, there is no obvious and scalable way with the currently proposed language construct to organize programs to handle them (the only proposed code organization techniques do not scale).  The response to this concern (since early coin days) from the proponents of the current specification was we should prototype the construct and see what patterns develop in code that uses the construct, and then adjust the specification based on that experience.
>>>
>>> That experience is necessary because it might not be possible to compatibly address problems that experience may expose.  The developers associated with project coin have no doubt written lots of new code using the feature and reported their experience attempting to handle suppressed exceptions to the jsr 224 mailing list, but we listeners on the coin list have unfortunately not gained the benefit of that discussion.  The discussion shown publicly on this list is insufficient in my mind to support an assumption that the current mechanism has passed scrutiny from this point of view.  Therefore I would ask the jsr 244 members to please summarize the relevant experience.
>>>
>>> Cheers,
>>> Neal
>>>
>>> On Fri, Jun 24, 2011 at 3:37 PM,  <joe.darcy at oracle.com> wrote:
>>>
>>> Hello.
>>>
>>> FYI, the proposed final draft specification of JSR 334 can now be
>>> downloaded from:
>>> http://jcp.org/aboutJava/communityprocess/pfd/jsr334/index.html
>>>
>>> -Joe
>>>
>>>
>>>
>>>       


From neal at gafter.com  Wed Jun 29 21:45:36 2011
From: neal at gafter.com (Neal Gafter)
Date: Wed, 29 Jun 2011 21:45:36 -0700
Subject: ARM: preserve supressed exceptions due to throw in finally block
In-Reply-To: <4BBE3200.5030609@sun.com>
References: <L0A3EF4EF330C45d8A3620BB076001DAB.1270720574.mail.keysoft.pt@MHS>
	<g2r15e8b9d21004081127q7f5372e3q14f8a2d3ffe04eba@mail.gmail.com>
	<4BBE3200.5030609@sun.com>
Message-ID: <BANLkTikNui-NNb5yRAD=krCZi9Tz6eFrqQ@mail.gmail.com>

This is the feedback thread from over a year ago I am discussing on
another thread.


---------- Forwarded message ----------
From: Joe Darcy <Joe.Darcy at sun.com>
Date: Thu, Apr 8, 2010 at 12:44 PM
Subject: Re: ARM: preserve supressed exceptions due to throw in finally block
To: Neal Gafter <neal at gafter.com>
Cc: Carlos Costa e Silva <carlos at keysoft.pt>, coin-dev at openjdk.java.net


On 04/08/10 11:27 AM, Neal Gafter wrote:
>
> Carlos-
>
> This has the same problem as the proposal for handling suppressed exceptions
> in ARM: we have no experience to suggest that this way of preserving
> suppressed exceptions is usable in realistic programs. ?This
> software-engineering aspect of ARM language design seems to have been
> largely ignored. ?I think more study of such software engineering aspects
> would be well advised before ARM or any extensions to it are moved into the
> jdk.
>
> Cheers,
> Neal
>
> On Thu, Apr 8, 2010 at 2:55 AM, Carlos Costa e Silva <carlos at keysoft.pt>wrote:
>
>
>

I would expect such study to be able to commence in earnest after
there is a version of ARM available in the JDK for people to play
with.

Language features of course evolve and are tuned as people gain
experience with them; this was true of generics I would expect this to
be true of ARM too.

-Joe


From neal at gafter.com  Wed Jun 29 21:46:49 2011
From: neal at gafter.com (Neal Gafter)
Date: Wed, 29 Jun 2011 21:46:49 -0700
Subject: FYI, JSR 334 has reached proposed final draft
In-Reply-To: <4E0BE521.2090907@oracle.com>
References: <4E0511A3.50502@oracle.com>
	<BANLkTintwmy5MbO6dCSE=+CGBHZ=SqLifg@mail.gmail.com>
	<BANLkTikPogXt5qYkrQNwa7-X0qFdnnt-Xg@mail.gmail.com>
	<BANLkTimDAgkcDrE731mWZm+f2+ZYwJV=nw@mail.gmail.com>
	<4E0BE521.2090907@oracle.com>
Message-ID: <BANLkTinyyGxn=4ML_zbyf6ZAxN=RQD0Wvg@mail.gmail.com>

I'm here referring to very early feedback I gave on this list. ?The
response was to see what experience develops and adjust accordingly.
The elapsed time since my comments has been over a year.

On Wednesday, June 29, 2011, ?<joe.darcy at oracle.com> wrote:
> Neal,
>
> The coin-dev mailing list is not a venue with a service level agreement promising a two business day or less turn-around-time to requests of arbitrary size.

>