Are there plans to support Java 7 features in Groovy 1.8?
Locked
Are there plans to support Java 7 features in Groovy 1.8?
 
|
Are there plans to support some of the proposed Java 7 features in Groovy 1.8? For example, I really like the "catch (ExceptionA | ExceptionB)" idea, and it should be fairly easy to implement.
Cheers, Peter |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
Supporting Java 7 features is on the roadmap for 1.8, so yes.
But we haven't really discussed yet the details. What should we support, in what form, to which extent, etc, are open for debate! Guillaume On Thu, Jul 1, 2010 at 23:59, Peter Niederwieser <[hidden email]> wrote: > > Are there plans to support some of the proposed Java 7 features in Groovy > 1.8? For example, I really like the "catch (ExceptionA | ExceptionB)" idea, > and it should be fairly easy to implement. > > Cheers, > Peter > -- > View this message in context: http://groovy.329449.n5.nabble.com/Are-there-plans-to-support-Java-7-features-in-Groovy-1-8-tp512472p512472.html > Sent from the groovy - dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
> What should we support, in what form, to which extent, etc, are open for debate!
We will also need to make a "Groovy" API around the new NIO2 API being released. -- Hamlet D'Arcy [hidden email] On Fri, Jul 2, 2010 at 8:59 PM, Guillaume Laforge <[hidden email]> wrote: > Supporting Java 7 features is on the roadmap for 1.8, so yes. > But we haven't really discussed yet the details. > What should we support, in what form, to which extent, etc, are open for debate! > > Guillaume > > On Thu, Jul 1, 2010 at 23:59, Peter Niederwieser <[hidden email]> wrote: >> >> Are there plans to support some of the proposed Java 7 features in Groovy >> 1.8? For example, I really like the "catch (ExceptionA | ExceptionB)" idea, >> and it should be fairly easy to implement. >> >> Cheers, >> Peter >> -- >> View this message in context: http://groovy.329449.n5.nabble.com/Are-there-plans-to-support-Java-7-features-in-Groovy-1-8-tp512472p512472.html >> Sent from the groovy - dev mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > > -- > Guillaume Laforge > Groovy Project Manager > Head of Groovy Development at SpringSource > http://www.springsource.com/g2one > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
Back on this JDK/Java 7 topic...
Do we have/know the final expected coverage of what we'll have in 7? Especially with regards to Project Coin's enhancements? According to http://blogs.sun.com/darcy/entry/project_coin_final_five - Strings in switch: Groovy's own switch already supports that and much more - Automatic Resource Management: there was a recent thread on InfoQ about that http://www.infoq.com/news/2010/08/arm-blocks and I think I saw a blog post saying it was in the latest OpenJDK - Improved Type Inference for Generic Instance Creation (that's the diamond thing) - Simplified Varargs Method Invocation - An omnibus proposal for better integral literals: this one shouldn't be a big change in the Groovy grammar I believe (but I'm not the Antlr expert so don't quote me on this) - Language support for Collections: I think this is about having native syntax for lists and maps, but I don't recall the details, but we'll have to see how it's compatible or conflicts with Groovy's choices - Language support for JSR 292: I think this is still in flux, in terms of syntax, as it recently changed those past weeks We'll need to see what to support and to which extent. Supporting some of these JDK 7 aspects on JDK 5+ is also a nice appeal to Java developers who can't just upgrade! And we'll need to see who wants to work on what! Guillaume On Mon, Jul 5, 2010 at 14:14, Hamlet D'Arcy <[hidden email]> wrote: >> What should we support, in what form, to which extent, etc, are open for debate! > > We will also need to make a "Groovy" API around the new NIO2 API being > released. > > -- > Hamlet D'Arcy > [hidden email] > > > > On Fri, Jul 2, 2010 at 8:59 PM, Guillaume Laforge <[hidden email]> wrote: >> Supporting Java 7 features is on the roadmap for 1.8, so yes. >> But we haven't really discussed yet the details. >> What should we support, in what form, to which extent, etc, are open for debate! >> >> Guillaume >> >> On Thu, Jul 1, 2010 at 23:59, Peter Niederwieser <[hidden email]> wrote: >>> >>> Are there plans to support some of the proposed Java 7 features in Groovy >>> 1.8? For example, I really like the "catch (ExceptionA | ExceptionB)" idea, >>> and it should be fairly easy to implement. >>> >>> Cheers, >>> Peter >>> -- >>> View this message in context: http://groovy.329449.n5.nabble.com/Are-there-plans-to-support-Java-7-features-in-Groovy-1-8-tp512472p512472.html >>> Sent from the groovy - dev mailing list archive at Nabble.com. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >> >> >> >> -- >> Guillaume Laforge >> Groovy Project Manager >> Head of Groovy Development at SpringSource >> http://www.springsource.com/g2one >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
Guillaume Laforge schrieb:
> Back on this JDK/Java 7 topic... > > Do we have/know the final expected coverage of what we'll have in 7? > Especially with regards to Project Coin's enhancements? > > According to http://blogs.sun.com/darcy/entry/project_coin_final_five [...] > - Automatic Resource Management: there was a recent thread on InfoQ > about that http://www.infoq.com/news/2010/08/arm-blocks and I think I > saw a blog post saying it was in the latest OpenJDK writing > try ( > FileInputStream in = new FileInputStream("xanadu.txt"); > FileOutputStream out = new FileOutputStream("outagain.txt") > ) { > int c; > while((c=in.read()) != -1 ) > out.write(); > } looks so wrong to me... sure it can reduce the need for finally blocks... still... we can of course use what we use for the "for loop" here. > - Improved Type Inference for Generic Instance Creation (that's the > diamond thing) that shouldn't be a big change since we simply ignore generics at that level. > - Simplified Varargs Method Invocation this is only about *not* warning or warning in a different way... so I tihnk nothing to do for Groovy since we don't warn at all. > - An omnibus proposal for better integral literals: this one shouldn't > be a big change in the Groovy grammar I believe (but I'm not the Antlr > expert so don't quote me on this) I think it is not such a big thing, should be a small change. > - Language support for Collections: I think this is about having > native syntax for lists and maps, but I don't recall the details, but > we'll have to see how it's compatible or conflicts with Groovy's > choices If I am right they use [] for lists, {} for sets and {a:b} for maps. The lists are no problem, but sets and our closures look a bit alike. In def foo = {1} It is then unclear if foo is a closure or a set. Or we go the same route as we did for arrays here and say that we don't support this. I see of course similar problems for Java should they ever have a very short syntax for some kind of closure. I think in accepting this they made quite a mistake. And while you will be able to express the empty set using {}, you would have to use the same to express the empty map... so no empty map.. ah well.. {a:b} of course conflicts with our way of expressing maps. Well, not really conflict, it is just different. But it may confuse users. > - Language support for JSR 292: I think this is still in flux, in > terms of syntax, as it recently changed those past weeks always does ;) > We'll need to see what to support and to which extent. > Supporting some of these JDK 7 aspects on JDK 5+ is also a nice appeal > to Java developers who can't just upgrade! > > And we'll need to see who wants to work on what! noone stepping forward? bummer bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
On Tue, Aug 31, 2010 at 12:44, Jochen Theodorou <[hidden email]> wrote: Guillaume Laforge schrieb: Yes, I agree with you :-( Hijacking "try" doesn't sound quite right, and as someone said on a blog somewhere, they had better introduce something like "using" in C#.
We can also decide to not support that syntax! We could just support the AutoCloseable interface in our DGM methods somehow. It's still up for debate, and we don't have to support all these things, we're free to make some choices :-)
Good. - Simplified Varargs Method Invocation One item less :-)
From what I understood from the proposal, the idea is to have the ability to put some _ here and there in the literals.
Those _ are actually ignored, and are really just for making things a bit more readable for large numbers. So I also don't expect this to be a big grammar change.
I've got the feeling we should keep the status quo and not support those new syntaxes, since Groovy already provide its own.
That's why I re-activated that thread, to see if we have some committers or contributors who are game :-) -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
The feature that is forgotten is is NIO2.
The GDK adds a bunch of methods to java.io.File and directory searching stuff. We'll need to add some sor tof parity for the new NIO2 API. The good news is NIO 2 is finished and hasn't changed in a while, and it is well documented. This is a fun and sort of easy bit of work. Mostly analysis and then a bunch of new DGM methods. -- Hamlet D'Arcy [hidden email] On Tue, Aug 31, 2010 at 12:55 PM, Guillaume Laforge <[hidden email]> wrote: > > On Tue, Aug 31, 2010 at 12:44, Jochen Theodorou <[hidden email]> wrote: >> >> Guillaume Laforge schrieb: >>> >>> Back on this JDK/Java 7 topic... >>> >>> Do we have/know the final expected coverage of what we'll have in 7? >>> Especially with regards to Project Coin's enhancements? >>> >>> According to http://blogs.sun.com/darcy/entry/project_coin_final_five >> >> [...] >>> >>> - Automatic Resource Management: there was a recent thread on InfoQ >>> about that http://www.infoq.com/news/2010/08/arm-blocks and I think I >>> saw a blog post saying it was in the latest OpenJDK >> >> writing >> >>> try ( >>> FileInputStream in = new FileInputStream("xanadu.txt"); >>> FileOutputStream out = new FileOutputStream("outagain.txt") >>> ) { >>> int c; >>> while((c=in.read()) != -1 ) >>> out.write(); >>> } >> >> looks so wrong to me... sure it can reduce the need for finally blocks... >> still... we can of course use what we use for the "for loop" here. > > Yes, I agree with you :-( > Hijacking "try" doesn't sound quite right, and as someone said on a blog > somewhere, they had better introduce something like "using" in C#. > We can also decide to not support that syntax! > We could just support the AutoCloseable interface in our DGM methods > somehow. > It's still up for debate, and we don't have to support all these things, > we're free to make some choices :-) > >>> >>> - Improved Type Inference for Generic Instance Creation (that's the >>> diamond thing) >> >> that shouldn't be a big change since we simply ignore generics at that >> level. > > Good. > >>> >>> - Simplified Varargs Method Invocation >> >> this is only about *not* warning or warning in a different way... so I >> tihnk nothing to do for Groovy since we don't warn at all. > > One item less :-) > >>> >>> - An omnibus proposal for better integral literals: this one shouldn't >>> be a big change in the Groovy grammar I believe (but I'm not the Antlr >>> expert so don't quote me on this) >> >> I think it is not such a big thing, should be a small change. > > From what I understood from the proposal, the idea is to have the ability to > put some _ here and there in the literals. > Those _ are actually ignored, and are really just for making things a bit > more readable for large numbers. > So I also don't expect this to be a big grammar change. > >>> >>> - Language support for Collections: I think this is about having >>> native syntax for lists and maps, but I don't recall the details, but >>> we'll have to see how it's compatible or conflicts with Groovy's >>> choices >> >> If I am right they use [] for lists, {} for sets and {a:b} for maps. The >> lists are no problem, but sets and our closures look a bit alike. In >> >> def foo = {1} >> >> It is then unclear if foo is a closure or a set. Or we go the same route >> as we did for arrays here and say that we don't support this. I see of >> course similar problems for Java should they ever have a very short syntax >> for some kind of closure. I think in accepting this they made quite a >> mistake. And while you will be able to express the empty set using {}, you >> would have to use the same to express the empty map... so no empty map.. ah >> well.. {a:b} of course conflicts with our way of expressing maps. Well, not >> really conflict, it is just different. But it may confuse users. > > I've got the feeling we should keep the status quo and not support those new > syntaxes, since Groovy already provide its own. > >>> >>> - Language support for JSR 292: I think this is still in flux, in >>> terms of syntax, as it recently changed those past weeks >> >> always does ;) >> >>> We'll need to see what to support and to which extent. >>> Supporting some of these JDK 7 aspects on JDK 5+ is also a nice appeal >>> to Java developers who can't just upgrade! >>> >>> And we'll need to see who wants to work on what! >> >> noone stepping forward? bummer > > That's why I re-activated that thread, to see if we have some committers or > contributors who are game :-) > > -- > Guillaume Laforge > Groovy Project Manager > Head of Groovy Development at SpringSource > http://www.springsource.com/g2one > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
So we have a volunteer :-)
On Thu, Sep 2, 2010 at 20:48, Hamlet D'Arcy <[hidden email]> wrote: The feature that is forgotten is is NIO2. -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
I'd also volunteer for that. ( Hi! Been a while - I have a son now. )
On Sep 2, 2010, at 12:02 PM, Guillaume Laforge wrote: So we have a volunteer :-) |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
Excellent, Hamlet and Merlyn, where do we start? :-)
Guillaume On Fri, Sep 3, 2010 at 16:27, Merlyn Albery-Speyer <[hidden email]> wrote: > I'd also volunteer for that. ( Hi! Been a while - I have a son now. ) > On Sep 2, 2010, at 12:02 PM, Guillaume Laforge wrote: > > So we have a volunteer :-) > > On Thu, Sep 2, 2010 at 20:48, Hamlet D'Arcy <[hidden email]> wrote: >> >> The feature that is forgotten is is NIO2. >> The GDK adds a bunch of methods to java.io.File and directory >> searching stuff. We'll need to add some sor tof parity for the new >> NIO2 API. >> >> The good news is NIO 2 is finished and hasn't changed in a while, and >> it is well documented. >> >> This is a fun and sort of easy bit of work. Mostly analysis and then a >> bunch of new DGM methods. >> >> -- >> Hamlet D'Arcy >> [hidden email] >> >> >> >> On Tue, Aug 31, 2010 at 12:55 PM, Guillaume Laforge >> <[hidden email]> wrote: >> > >> > On Tue, Aug 31, 2010 at 12:44, Jochen Theodorou <[hidden email]> >> > wrote: >> >> >> >> Guillaume Laforge schrieb: >> >>> >> >>> Back on this JDK/Java 7 topic... >> >>> >> >>> Do we have/know the final expected coverage of what we'll have in 7? >> >>> Especially with regards to Project Coin's enhancements? >> >>> >> >>> According to http://blogs.sun.com/darcy/entry/project_coin_final_five >> >> >> >> [...] >> >>> >> >>> - Automatic Resource Management: there was a recent thread on InfoQ >> >>> about that http://www.infoq.com/news/2010/08/arm-blocks and I think I >> >>> saw a blog post saying it was in the latest OpenJDK >> >> >> >> writing >> >> >> >>> try ( >> >>> FileInputStream in = new FileInputStream("xanadu.txt"); >> >>> FileOutputStream out = new FileOutputStream("outagain.txt") >> >>> ) { >> >>> int c; >> >>> while((c=in.read()) != -1 ) >> >>> out.write(); >> >>> } >> >> >> >> looks so wrong to me... sure it can reduce the need for finally >> >> blocks... >> >> still... we can of course use what we use for the "for loop" here. >> > >> > Yes, I agree with you :-( >> > Hijacking "try" doesn't sound quite right, and as someone said on a blog >> > somewhere, they had better introduce something like "using" in C#. >> > We can also decide to not support that syntax! >> > We could just support the AutoCloseable interface in our DGM methods >> > somehow. >> > It's still up for debate, and we don't have to support all these things, >> > we're free to make some choices :-) >> > >> >>> >> >>> - Improved Type Inference for Generic Instance Creation (that's the >> >>> diamond thing) >> >> >> >> that shouldn't be a big change since we simply ignore generics at that >> >> level. >> > >> > Good. >> > >> >>> >> >>> - Simplified Varargs Method Invocation >> >> >> >> this is only about *not* warning or warning in a different way... so I >> >> tihnk nothing to do for Groovy since we don't warn at all. >> > >> > One item less :-) >> > >> >>> >> >>> - An omnibus proposal for better integral literals: this one shouldn't >> >>> be a big change in the Groovy grammar I believe (but I'm not the Antlr >> >>> expert so don't quote me on this) >> >> >> >> I think it is not such a big thing, should be a small change. >> > >> > From what I understood from the proposal, the idea is to have the >> > ability to >> > put some _ here and there in the literals. >> > Those _ are actually ignored, and are really just for making things a >> > bit >> > more readable for large numbers. >> > So I also don't expect this to be a big grammar change. >> > >> >>> >> >>> - Language support for Collections: I think this is about having >> >>> native syntax for lists and maps, but I don't recall the details, but >> >>> we'll have to see how it's compatible or conflicts with Groovy's >> >>> choices >> >> >> >> If I am right they use [] for lists, {} for sets and {a:b} for maps. >> >> The >> >> lists are no problem, but sets and our closures look a bit alike. In >> >> >> >> def foo = {1} >> >> >> >> It is then unclear if foo is a closure or a set. Or we go the same >> >> route >> >> as we did for arrays here and say that we don't support this. I see of >> >> course similar problems for Java should they ever have a very short >> >> syntax >> >> for some kind of closure. I think in accepting this they made quite a >> >> mistake. And while you will be able to express the empty set using {}, >> >> you >> >> would have to use the same to express the empty map... so no empty >> >> map.. ah >> >> well.. {a:b} of course conflicts with our way of expressing maps. Well, >> >> not >> >> really conflict, it is just different. But it may confuse users. >> > >> > I've got the feeling we should keep the status quo and not support those >> > new >> > syntaxes, since Groovy already provide its own. >> > >> >>> >> >>> - Language support for JSR 292: I think this is still in flux, in >> >>> terms of syntax, as it recently changed those past weeks >> >> >> >> always does ;) >> >> >> >>> We'll need to see what to support and to which extent. >> >>> Supporting some of these JDK 7 aspects on JDK 5+ is also a nice appeal >> >>> to Java developers who can't just upgrade! >> >>> >> >>> And we'll need to see who wants to work on what! >> >> >> >> noone stepping forward? bummer >> > >> > That's why I re-activated that thread, to see if we have some committers >> > or >> > contributors who are game :-) >> > >> > -- >> > Guillaume Laforge >> > Groovy Project Manager >> > Head of Groovy Development at SpringSource >> > http://www.springsource.com/g2one >> > >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > > -- > Guillaume Laforge > Groovy Project Manager > Head of Groovy Development at SpringSource > http://www.springsource.com/g2one > > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
On Fri, Sep 3, 2010 at 8:30 PM, Guillaume Laforge <[hidden email]> wrote:
Excellent, Hamlet and Merlyn, where do we start? :-) Congratulations and welcome back, Merlyn! How old is your son now? |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
Cheers. Five and a half months.
On Sep 3, 2010, at 9:38 AM, Roshan Dawrani wrote:
|
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
In reply to this post by Guillaume Laforge-4
The September 2nd build of Java 1.7.0 seems to work fine with Groovy
1.7.4. I could use File.toPath() without issues. I haven't played around with nio2 so I don't know what the Java idioms are for its usage. However, I don't imagine that translating the File GDM's will be hard. For starters I'll try coding DGM getText(Path) against trunk to see if anything trips me up. On Sep 3, 2010, at 8:00 AM, Guillaume Laforge wrote: > Excellent, Hamlet and Merlyn, where do we start? :-) > > Guillaume > > On Fri, Sep 3, 2010 at 16:27, Merlyn Albery-Speyer > <[hidden email]> wrote: >> I'd also volunteer for that. ( Hi! Been a while - I have a son now. ) >> On Sep 2, 2010, at 12:02 PM, Guillaume Laforge wrote: >> >> So we have a volunteer :-) >> >> On Thu, Sep 2, 2010 at 20:48, Hamlet D'Arcy <[hidden email]> >> wrote: >>> >>> The feature that is forgotten is is NIO2. >>> The GDK adds a bunch of methods to java.io.File and directory >>> searching stuff. We'll need to add some sor tof parity for the new >>> NIO2 API. >>> >>> The good news is NIO 2 is finished and hasn't changed in a while, >>> and >>> it is well documented. >>> >>> This is a fun and sort of easy bit of work. Mostly analysis and >>> then a >>> bunch of new DGM methods. >>> >>> -- >>> Hamlet D'Arcy >>> [hidden email] >>> >>> >>> >>> On Tue, Aug 31, 2010 at 12:55 PM, Guillaume Laforge >>> <[hidden email]> wrote: >>>> >>>> On Tue, Aug 31, 2010 at 12:44, Jochen Theodorou <[hidden email]> >>>> wrote: >>>>> >>>>> Guillaume Laforge schrieb: >>>>>> >>>>>> Back on this JDK/Java 7 topic... >>>>>> >>>>>> Do we have/know the final expected coverage of what we'll have >>>>>> in 7? >>>>>> Especially with regards to Project Coin's enhancements? >>>>>> >>>>>> According to http://blogs.sun.com/darcy/entry/project_coin_final_five >>>>> >>>>> [...] >>>>>> >>>>>> - Automatic Resource Management: there was a recent thread on >>>>>> InfoQ >>>>>> about that http://www.infoq.com/news/2010/08/arm-blocks and I >>>>>> think I >>>>>> saw a blog post saying it was in the latest OpenJDK >>>>> >>>>> writing >>>>> >>>>>> try ( >>>>>> FileInputStream in = new FileInputStream("xanadu.txt"); >>>>>> FileOutputStream out = new FileOutputStream("outagain.txt") >>>>>> ) { >>>>>> int c; >>>>>> while((c=in.read()) != -1 ) >>>>>> out.write(); >>>>>> } >>>>> >>>>> looks so wrong to me... sure it can reduce the need for finally >>>>> blocks... >>>>> still... we can of course use what we use for the "for loop" here. >>>> >>>> Yes, I agree with you :-( >>>> Hijacking "try" doesn't sound quite right, and as someone said on >>>> a blog >>>> somewhere, they had better introduce something like "using" in C#. >>>> We can also decide to not support that syntax! >>>> We could just support the AutoCloseable interface in our DGM >>>> methods >>>> somehow. >>>> It's still up for debate, and we don't have to support all these >>>> things, >>>> we're free to make some choices :-) >>>> >>>>>> >>>>>> - Improved Type Inference for Generic Instance Creation (that's >>>>>> the >>>>>> diamond thing) >>>>> >>>>> that shouldn't be a big change since we simply ignore generics >>>>> at that >>>>> level. >>>> >>>> Good. >>>> >>>>>> >>>>>> - Simplified Varargs Method Invocation >>>>> >>>>> this is only about *not* warning or warning in a different >>>>> way... so I >>>>> tihnk nothing to do for Groovy since we don't warn at all. >>>> >>>> One item less :-) >>>> >>>>>> >>>>>> - An omnibus proposal for better integral literals: this one >>>>>> shouldn't >>>>>> be a big change in the Groovy grammar I believe (but I'm not >>>>>> the Antlr >>>>>> expert so don't quote me on this) >>>>> >>>>> I think it is not such a big thing, should be a small change. >>>> >>>> From what I understood from the proposal, the idea is to have the >>>> ability to >>>> put some _ here and there in the literals. >>>> Those _ are actually ignored, and are really just for making >>>> things a >>>> bit >>>> more readable for large numbers. >>>> So I also don't expect this to be a big grammar change. >>>> >>>>>> >>>>>> - Language support for Collections: I think this is about having >>>>>> native syntax for lists and maps, but I don't recall the >>>>>> details, but >>>>>> we'll have to see how it's compatible or conflicts with Groovy's >>>>>> choices >>>>> >>>>> If I am right they use [] for lists, {} for sets and {a:b} for >>>>> maps. >>>>> The >>>>> lists are no problem, but sets and our closures look a bit >>>>> alike. In >>>>> >>>>> def foo = {1} >>>>> >>>>> It is then unclear if foo is a closure or a set. Or we go the same >>>>> route >>>>> as we did for arrays here and say that we don't support this. I >>>>> see of >>>>> course similar problems for Java should they ever have a very >>>>> short >>>>> syntax >>>>> for some kind of closure. I think in accepting this they made >>>>> quite a >>>>> mistake. And while you will be able to express the empty set >>>>> using {}, >>>>> you >>>>> would have to use the same to express the empty map... so no empty >>>>> map.. ah >>>>> well.. {a:b} of course conflicts with our way of expressing >>>>> maps. Well, >>>>> not >>>>> really conflict, it is just different. But it may confuse users. >>>> >>>> I've got the feeling we should keep the status quo and not >>>> support those >>>> new >>>> syntaxes, since Groovy already provide its own. >>>> >>>>>> >>>>>> - Language support for JSR 292: I think this is still in flux, in >>>>>> terms of syntax, as it recently changed those past weeks >>>>> >>>>> always does ;) >>>>> >>>>>> We'll need to see what to support and to which extent. >>>>>> Supporting some of these JDK 7 aspects on JDK 5+ is also a nice >>>>>> appeal >>>>>> to Java developers who can't just upgrade! >>>>>> >>>>>> And we'll need to see who wants to work on what! >>>>> >>>>> noone stepping forward? bummer >>>> >>>> That's why I re-activated that thread, to see if we have some >>>> committers >>>> or >>>> contributors who are game :-) >>>> >>>> -- >>>> Guillaume Laforge >>>> Groovy Project Manager >>>> Head of Groovy Development at SpringSource >>>> http://www.springsource.com/g2one >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> >> >> -- >> Guillaume Laforge >> Groovy Project Manager >> Head of Groovy Development at SpringSource >> http://www.springsource.com/g2one >> >> > > > > -- > Guillaume Laforge > Groovy Project Manager > Head of Groovy Development at SpringSource > http://www.springsource.com/g2one > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
In reply to this post by Guillaume Laforge-4
Hi all,
I have a changeset to provide Path.getText(). The majority of the changes are for the ant build file. I've followed the conventions that we're using for 1.6, which have two implications: 1) Groovy developers using IDEs and 1.6 would need to exclude the "v7" source and test packages to avoid compiler errors. 2) Anyone building a release (e.g. Bamboo) with 1.6 would quietly omit the 1.7 DGM methods from the distribution. One obstacle that I haven't yet looked into are two test failures that I get using 1.7.0-ea that I don't get using 1.6: org .codehaus .groovy .ant .GroovycTest .testGroovyc_Joint_NoFork_NestedCompilerArg_WithGroovyClasspath org.codehaus.groovy.transform.DelegateTransformTest.testLock Finally, how should I best share the code? Offline with Hamlet, or as an attachment on a Jira issue? Cheers, Merlyn On Sep 3, 2010, at 8:00 AM, Guillaume Laforge wrote: > Excellent, Hamlet and Merlyn, where do we start? :-) --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
Patch attached to a Jira issue would be good. That would allow others to pitch in as time permitted them, e.g. to make sure gradle build follows ant build changes. Cheers, Paul. On 5/09/2010 12:00 PM, Merlyn Albery-Speyer wrote: > Hi all, > > I have a changeset to provide Path.getText(). The majority of the changes are for the ant build file. I've followed the conventions that we're using for 1.6, which have two implications: > 1) Groovy developers using IDEs and 1.6 would need to exclude the "v7" source and test packages to avoid compiler errors. > 2) Anyone building a release (e.g. Bamboo) with 1.6 would quietly omit the 1.7 DGM methods from the distribution. > > One obstacle that I haven't yet looked into are two test failures that I get using 1.7.0-ea that I don't get using 1.6: > > org.codehaus.groovy.ant.GroovycTest.testGroovyc_Joint_NoFork_NestedCompilerArg_WithGroovyClasspath > org.codehaus.groovy.transform.DelegateTransformTest.testLock > > Finally, how should I best share the code? Offline with Hamlet, or as an attachment on a Jira issue? > > Cheers, > Merlyn > > On Sep 3, 2010, at 8:00 AM, Guillaume Laforge wrote: > >> Excellent, Hamlet and Merlyn, where do we start? :-) > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
And we're off to a fast start! Great.
Just for reference, the NIO2 home page is here: http://java.sun.com/developer/technicalArticles/javase/nio/ There are also a ton of blog posts with examples already on the web. Before calling this NIO2 support "done", I would like at least these following issues addressed. This is my todo list for NIO2, we can certainly add to it or turn it into a GEP for easier documentation (which has the benefit of making Guillaume's "Groovy: To Infinity and Beyond" slide deck easier to update :) All of the GDK File API needs to be on Path, not just the getText method: http://groovy.codehaus.org/groovy-jdk/java/io/File.html Groovy has a FileNameFinder and FileNameRegExFinder. This stuff needs to work with Paths as well: http://mrhaki.blogspot.com/2009/11/groovy-goodness-finding-files-with.html I haven't looked at each file in this list yet, but we need to analyze these Groovy source files and see if any parallel Path implementations are needed. The first 3 files look like the most important: ./groovy/util/IFileNameFinder.java ./groovy/io/FileType.java ./groovy/io/FileVisitResult.java ./org/codehaus/groovy/runtime/WritableFile.java ./org/codehaus/groovy/ant/FileIterator.java ./org/codehaus/groovy/ant/FileScanner.java ./org/codehaus/groovy/control/io/FileReaderSource.java I couldn't find any instances of this in Groovy-core, but any "asType(File)" methods need a parallel "asType(Path)" In NIO2, I believe File.list and another method now return an interator, which enables this method to work better over networks. We need to update the File GDK to use this approach by default to also support network dir or ls style listings. NIO2 has a new FileVisitor class. We need to unify this new FileVisitor JDK method with what Groovy does today in with GDK with the .eachFile method. NIO2 contains a new WatchService API. We need to probably provide a GDK on WatchService to make it easy to work with using closures, etc. This is the most interesting piece of work IMO. There is no NIO2 backport for JDK5, which is a shame because it would be way cool to claim Groovy 1.8 has NIO2 support before JDK 7 is released. Anyone else know of anything that needs updating? -- Hamlet D'Arcy [hidden email] On Sun, Sep 5, 2010 at 5:16 AM, Paul King <[hidden email]> wrote: > > Patch attached to a Jira issue would be good. That would allow others to > pitch in as time permitted them, e.g. to make sure gradle build follows > ant build changes. > > Cheers, Paul. > > On 5/09/2010 12:00 PM, Merlyn Albery-Speyer wrote: >> >> Hi all, >> >> I have a changeset to provide Path.getText(). The majority of the changes >> are for the ant build file. I've followed the conventions that we're using >> for 1.6, which have two implications: >> 1) Groovy developers using IDEs and 1.6 would need to exclude the "v7" >> source and test packages to avoid compiler errors. >> 2) Anyone building a release (e.g. Bamboo) with 1.6 would quietly omit the >> 1.7 DGM methods from the distribution. >> >> One obstacle that I haven't yet looked into are two test failures that I >> get using 1.7.0-ea that I don't get using 1.6: >> >> >> org.codehaus.groovy.ant.GroovycTest.testGroovyc_Joint_NoFork_NestedCompilerArg_WithGroovyClasspath >> org.codehaus.groovy.transform.DelegateTransformTest.testLock >> >> Finally, how should I best share the code? Offline with Hamlet, or as an >> attachment on a Jira issue? >> >> Cheers, >> Merlyn >> >> On Sep 3, 2010, at 8:00 AM, Guillaume Laforge wrote: >> >>> Excellent, Hamlet and Merlyn, where do we start? :-) >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
On 5/09/2010 5:29 PM, Hamlet D'Arcy wrote:
> NIO2 has a new FileVisitor class. We need to unify this new > FileVisitor JDK method with what Groovy does today in with GDK > with the .eachFile method. As well as the .eachFileXXX methods and the .eachDirXXX methods we should include the .traverse method when looking through potential places for unification. The .traverse method's primary role was to make some FileVisitor like functionality available in the pre-JDK 7 world but having NIO2 there might open up some more possibilities. There was also some thought at the time of having additional overloaded traverse methods with a more statically typed flavor rather than just the current Map solution. I guess now is a good time to also look at that option. Cheers, Paul. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
In reply to this post by Hamlet D'Arcy
On 5/09/2010 5:29 PM, Hamlet D'Arcy wrote:
> I haven't looked at each file in this list yet, but we need to analyze > these Groovy source files and see if any parallel Path implementations > are needed. > [...] > ./org/codehaus/groovy/ant/FileIterator.java > ./org/codehaus/groovy/ant/FileScanner.java As a somewhat parallel activity, if anyone has an itch to look at Ant 1.8.x features, we haven't looked to see if there are any other things we should support over and above AntBuilder and FileScanner which were designed for earlier Ant versions, e.g. should we have any special support for ResourceCollections, e.g. a ResourceScanner counterpart to FileScanner? Or are such Ant features easy enough to use in there raw form? Just a thought. Cheers, Paul. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: Are there plans to support Java 7 features in Groovy 1.8?
|
|
In reply to this post by Hamlet D'Arcy
On Sep 5, 2010, at 12:29 AM, Hamlet D'Arcy wrote: > Before calling this NIO2 support "done", I would like at least these > following issues addressed. This is my todo list for NIO2, we can > certainly add to it or turn it into a GEP for easier documentation > (which has the benefit of making Guillaume's "Groovy: To Infinity and > Beyond" slide deck easier to update :) Yes. It sounds like GEP would be a better fit. > > There is no NIO2 backport for JDK5, which is a shame because it would > be way cool to claim Groovy 1.8 has NIO2 support before JDK 7 is > released. > > Anyone else know of anything that needs updating? > Very thorough! A couple of thoughts: On first pass it looks overly hard to determine if a Path is a directory or not. In fact all such FileAttributeView data are candidate for exposing directly on Path - mainly isDirectory, isSymbolicLink, lastModifiedTime. It'd be interesting to come up with a way of supporting the asynchronous operations. Perhaps something like path.async().eachLine { ... }. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
«
Return to groovy - dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |