Quantcast

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

classic Classic list List threaded Threaded
19 messages Options
12
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


12
Loading...