Quantcast

Are there plans to support Java 7 features in Groovy 1.8?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Are there plans to support Java 7 features in Groovy 1.8?

Peter Niederwieser
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Guillaume Laforge-4
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Hamlet D'Arcy
> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Guillaume Laforge-4
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Jochen Theodorou
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Guillaume Laforge-4

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Hamlet D'Arcy
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Guillaume Laforge-4
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Merlyn Albery-Speyer
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Guillaume Laforge-4
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Roshan Dawrani
On Fri, Sep 3, 2010 at 8:30 PM, Guillaume Laforge <[hidden email]> 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. )

Congratulations and welcome back, Merlyn! How old is your son now?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Merlyn Albery-Speyer
Cheers. Five and a half months.

On Sep 3, 2010, at 9:38 AM, Roshan Dawrani wrote:

On Fri, Sep 3, 2010 at 8:30 PM, Guillaume Laforge <[hidden email]> 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. )

Congratulations and welcome back, Merlyn! How old is your son now?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Merlyn Albery-Speyer
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Merlyn Albery-Speyer
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

paulk_asert

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Hamlet D'Arcy
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

paulk_asert
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

paulk_asert
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are there plans to support Java 7 features in Groovy 1.8?

Merlyn Albery-Speyer
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


Loading...