From joe.darcy at oracle.com Thu Nov 10 14:08:36 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 10 Nov 2011 14:08:36 -0800 Subject: Update on Coin futures from JavaOne In-Reply-To: <4E8BAA5A.2020207@oracle.com> References: <4E8BAA5A.2020207@oracle.com> Message-ID: <4EBC4B64.1010202@oracle.com> On 10/4/2011 5:52 PM, Joe Darcy wrote: > Hello. > > Earlier today, I presented my JavaOne session on "The Heads and Tails > of Project Coin." [1] The talk included some retrospectives from > developing the Coin features which I hope to write up in more detail > in the near future. > > Turning toward the future, the talk also spent a little time > discussing possible language changes coming in JDK 8. First, planning > for JDK 8 is on-going and the feature list is subject to change; the > JEP process [2] will be used to help define the roadmap going forward. > With those caveats, small language changes we're considering proposing > for JDK 8 include: > > Refinements to JDK 7 Coin features > try-with-resources on an effective final variable > removing restrictions on usage of diamond > @SafeVarargs on private methods > Collection literals(?) > Repeating Annotations(?) > Method and constructor parameter names at runtime(?) > [snip] JEPs now filed for Access to Parameter Names at Runtime http://openjdk.java.net/jeps/118 Repeating Annotations http://openjdk.java.net/jeps/120 -Joe From david.holmes at oracle.com Thu Nov 10 17:57:42 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2011 11:57:42 +1000 Subject: Update on Coin futures from JavaOne In-Reply-To: <4EBC4B64.1010202@oracle.com> References: <4E8BAA5A.2020207@oracle.com> <4EBC4B64.1010202@oracle.com> Message-ID: <4EBC8116.8080707@oracle.com> Hi Joe, On 11/11/2011 8:08 AM, Joe Darcy wrote: > JEPs now filed for > > Access to Parameter Names at Runtime > http://openjdk.java.net/jeps/118 Just wondering if compiler-dev is really the right mailing list on which to discuss a core-reflection update? The compiler has to be updated to support this but really it isn't about the compiler. This extends from the JVMS through to the VM, with core-libs in between. Maybe jdk8-dev would be better? Cheers, David > Repeating Annotations > http://openjdk.java.net/jeps/120 > > -Joe > From joe.darcy at oracle.com Sat Nov 12 17:33:53 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 12 Nov 2011 17:33:53 -0800 Subject: Update on Coin futures from JavaOne In-Reply-To: <4E8C0DE0.1020403@paradise.net.nz> References: <4E8BAA5A.2020207@oracle.com> <4E8C0DE0.1020403@paradise.net.nz> Message-ID: <4EBF1E81.6030704@oracle.com> Hi Bruce, Sorry for the belated reply. Yes, the omission of addressing the issue of providing additional literals to more sensibly initialize byte values was deliberate; we don't view addressing that as having as high a priority as addressing other shortcomings. Above a maintenance threshold, other small language changes will have to go through the JEP processes. For example, IMO changing the try-with-resources statement to accept an effectively final variable as a resource to manage (as opposed to requiring a new variable to be declared as done in Java SE 7) would *not* require a JEP. -Joe On 10/5/2011 12:57 AM, Bruce Chapman wrote: > Joe, > > Is the omission of byte literals (or alternatively unsigned literals, or > unsigned bytes) deliberate, or is there still intention to address this > somehow? > > Secondly, is the JEP process the way to propose further small language > enhancements? > > Bruce > > On 5/10/2011 1:52 p.m., Joe Darcy wrote: >> Hello. >> >> Earlier today, I presented my JavaOne session on "The Heads and Tails of >> Project Coin." [1] The talk included some retrospectives from >> developing the Coin features which I hope to write up in more detail in >> the near future. >> >> Turning toward the future, the talk also spent a little time discussing >> possible language changes coming in JDK 8. First, planning for JDK 8 is >> on-going and the feature list is subject to change; the JEP process [2] >> will be used to help define the roadmap going forward. With those >> caveats, small language changes we're considering proposing for JDK 8 >> include: >> >> Refinements to JDK 7 Coin features >> try-with-resources on an effective final variable >> removing restrictions on usage of diamond >> @SafeVarargs on private methods >> Collection literals(?) >> Repeating Annotations(?) >> Method and constructor parameter names at runtime(?) >> >> Personally, I would welcome programming with collection literals. >> Repeating annotations and the ability to retrieve the names of >> method/constructors at runtime are both long-standing requests from our >> colleagues in EE. >> >> However, with the broad scope of language and platform changes coming >> into JDK 8 courtesy Lambda and Jigsaw, all these smaller language >> changes have to be made somewhat opportunistically. For that reason, for >> JDK 8 we are *not* planning on having another open call for proposals as >> was done for Project Coin in JDK 7. >> >> -Joe >> >> [1] http://blogs.oracle.com/darcy/entry/project_coin_javaone2011 >> [2] http://openjdk.java.net/jeps/0 >> >> > From joe.darcy at oracle.com Sat Nov 12 17:35:31 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 12 Nov 2011 17:35:31 -0800 Subject: Update on Coin futures from JavaOne In-Reply-To: <4EBC8116.8080707@oracle.com> References: <4E8BAA5A.2020207@oracle.com> <4EBC4B64.1010202@oracle.com> <4EBC8116.8080707@oracle.com> Message-ID: <4EBF1EE3.8050106@oracle.com> Hi David, On 11/10/2011 5:57 PM, David Holmes wrote: > Hi Joe, > > On 11/11/2011 8:08 AM, Joe Darcy wrote: >> JEPs now filed for >> >> Access to Parameter Names at Runtime >> http://openjdk.java.net/jeps/118 > > Just wondering if compiler-dev is really the right mailing list on > which to discuss a core-reflection update? The compiler has to be > updated to support this but really it isn't about the compiler. This > extends from the JVMS through to the VM, with core-libs in between. > Maybe jdk8-dev would be better? > There are certainly aspects of this request that span the traditional mailing list topic boundaries; I'm sure the eventual review requests and discussions will span more than one list! -Joe From neal at gafter.com Sat Nov 12 23:35:17 2011 From: neal at gafter.com (Neal Gafter) Date: Sat, 12 Nov 2011 23:35:17 -0800 Subject: Update on Coin futures from JavaOne In-Reply-To: <4EBF1E81.6030704@oracle.com> References: <4E8BAA5A.2020207@oracle.com> <4E8C0DE0.1020403@paradise.net.nz> <4EBF1E81.6030704@oracle.com> Message-ID: On Sat, Nov 12, 2011 at 5:33 PM, Joe Darcy wrote: > Above a maintenance threshold, other small language changes will have to > go through the JEP processes. For example, IMO changing the > try-with-resources statement to accept an effectively final variable as > a resource to manage (as opposed to requiring a new variable to be > declared as done in Java SE 7) would *not* require a JEP. That's interesting, since a resource, for the purpose of try-with-resources, was defined as a value that cannot be used again once closed. Are you imagining that the definite assignment rules would be modified to produce an error if the variable were referenced after the try-with-resources statement? Or is this issue too trivial to even discuss? From joe.darcy at oracle.com Sun Nov 13 08:49:09 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 13 Nov 2011 08:49:09 -0800 Subject: Update on Coin futures from JavaOne In-Reply-To: References: <4E8BAA5A.2020207@oracle.com> <4E8C0DE0.1020403@paradise.net.nz> <4EBF1E81.6030704@oracle.com> Message-ID: <4EBFF505.3000602@oracle.com> Hi Neal, On 11/12/2011 11:35 PM, Neal Gafter wrote: > On Sat, Nov 12, 2011 at 5:33 PM, Joe Darcy > wrote: > > Above a maintenance threshold, other small language changes will > have to > go through the JEP processes. For example, IMO changing the > try-with-resources statement to accept an effectively final > variable as > a resource to manage (as opposed to requiring a new variable to be > declared as done in Java SE 7) would *not* require a JEP. > > > That's interesting, since a resource, for the purpose > of try-with-resources, was defined as a value that cannot be used > again once closed. Are you imagining that the definite assignment > rules would be modified to produce an error if the variable were > referenced after the try-with-resources statement? Or is this issue > too trivial to even discuss? Well the compiler isn't required to do any alias analysis to make sure someone doesn't stash a reference to the resource object such that it can be referenced outside of the scope of the try-with-resource block. So I wouldn't quite characterize the semantics of the resource handling as you have above. The general expression support in try-with-resources was dropped earlier this year for several reasons, including semantic problems if the resource was modified in the block. [1] [2] However, from using the feature, it would be handy if one didn't always have to introduce a new variable when a perfectly good effective final variable was around; having the variable be effectively final avoids semantic problems of the block calling close on your behalf. So, in short, I don't expect the DU/DA rules to be changed to account for this tweak to try-with-resources. -Joe [1] "Project Coin: JSR 334 Expert Group Update," http://blogs.oracle.com/darcy/entry/jsr_334_eg_update [2] http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002972.html From sebastian.sickelmann at gmx.de Sun Nov 20 20:40:50 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 21 Nov 2011 05:40:50 +0100 Subject: Optional Parameters Message-ID: <4EC9D652.1000704@gmx.de> Hi, While reading the suggestions on method chaining from Eirik Lygre at jdk8-dev yesterday the first mindset i got is another kind of "method chaining". Its more or less the idea that is described from Frediric Martini recently (01.09.2011) on this list but without the named parameters part. Maybe there are the same reasons why named parameters are not considered as coin feature. But i think a simple pattern which enables default-parameters and reduces "method-chaining" at compile-time ca be coin-ish enough. There are some places in jdk and many in other public libraries that use code like this. public class MyClass { public static final BarB BAR_DEFAULT_B = ...; public static final BarC BAR_DEFAULT_C = ...; public Bar foo(BarA a) { foo(a,MyClass.BAR_DEFAULT_B); } public Bar foo(BarA a,BarB b) { foo(a,b,MyClass.BAR_DEFAULT_C); } public Bar foo(BarA a,BarB b,BarC c) { ... } } The concrete types "Bar?" are really irrelevant. I think this code snipplet can be reduced to something like this. public class MyClass { public static final BarB BAR_DEFAULT_B = ...; public static final BarC BAR_DEFAULT_C = ...; public Bar foo(BarA a,BarB b=BAR_DEFAULT_B,BarC c=BAR_DEFAULT_C) { ... } } This can expand to be upper one, so this issue is just an stringtemplate expansion for the compiler. There is an javadoc issue too, but i think the most important part (the semantics of the default values) can be handled in the javadoc comment of the method that defines the default parameter values. I see mainly two implementation scenarios. The first result is described above. The second is replacing the complete list of parameters in every generated method. So the first method looks something like this: public Bar foo(BarA a) { foo(a,MyClass.BAR_DEFAULT_B,MyClass.BAR_DEFAULT_C); } I think the second implementation scenario is slightly better, because it reduces stack-traces sizes or is there a way to disable "stacktrace-insertion". The main downside i see is the "stacktrace-insertion". This can really confuse some programmers. And then there is the usual downside of reducing the syntactic-room for further changes to syntax and adding more complexity for implementators of IDEs. -- Sebastian