Re: Groovy 2.4.14 on JDK8 and JDK9

Sorry for being a bit late in replying. I tried Mr Haki's examples here and had no problems (I was using Oracle JDKs 9.0.4 and 1.8.0_161 and a recent OpenJDK 10): http://mrhaki.blogspot.com.au/2009/12/groovy-goodness-getting-groovy-with-dom.html Can you elaborate? Cheers, Paul. On Thu, Mar 8, 2

Re: About supporting `var` of Java10+

On 09.03.2018 00:01, Paul King wrote: But Java doesn't have a dynamic mode so it is difficult to offer the exact same behavior. We could prohibit "var" from being used in dynamic Groovy but users might expect to be able to cut and paste from Java and run in dynamic mode. I am convinced that

Re: About supporting `var` of Java10+

On 08.03.2018 14:13, Paul King wrote: On Thu, Mar 8, 2018 at 9:53 PM, mg > wrote: I would be interested to hear if you see some advantages of going down the #define var def route - apart from the obvious, that it is the easiest/fastest to imple

Re: About supporting `var` of Java10+

Hi Paul, 1. If I will assign a value to a variable later, I would use var with Java semantics. Without var I give the type of the variable explicitely as restrictive as possible. I would not use def (I only use def as the return value for a method returning an anonymous class instance

Re: About supporting `var` of Java10+

On Fri, Mar 9, 2018 at 5:46 AM, Aarjav Patel wrote: > Hi all, > > I do not know all of the intricacies in the difference between current > groovy def and the proposed java var. However as a groovy 'user' coming > from a Javan background, I would like or expect var in groovy to be > treated/behave

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Hi Remi, I have used Groovy exclusively for the last years, so not really used to Java lambdas, but why can't you use something along the line of: int result = switch (s) {     case "Foo" -> 1;     case "Bar" -> 2;     case default -> (System.out.println("Neither Foo nor Bar, hmmm...");  3; )

Re: About supporting `var` of Java10+

So in that one aspect of "assigning a value later on" your expectation is exactly like Java's "var" and Groovy's current "def"? On Thu, Mar 8, 2018 at 11:58 PM, mg wrote: > My argument was not in relation to the JEP, but a Groovy user story, in > relation to you saying, that I would not see a d

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

- Mail original - > De: "Jochen Theodorou" > À: "dev" > Envoyé: Jeudi 8 Mars 2018 19:51:57 > Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps) > On 08.03.2018 17:34, Remi Forax wrote: > [...] int accumulator = 0 LOOP: for (T element : someList) { a

Re: About supporting `var` of Java10+

Hi all, I do not know all of the intricacies in the difference between current groovy def and the proposed java var. However as a groovy 'user' coming from a Javan background, I would like or expect var in groovy to be treated/behave the same way as in java. def then would be an 'enhanced' version

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

On 08.03.2018 17:34, Remi Forax wrote: [...] int accumulator = 0 LOOP: for (T element : someList) { accumulator += switch (element.type) { case PLUS_ONE -> +1; case MINUS_ONE -> -1; case ERROR: break LOOP; case default -> 0 } } with the idea that element.type is

Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)

Hi Jochen, - Mail original - > De: "Jochen Theodorou" > À: "dev" > Envoyé: Vendredi 2 Mars 2018 00:57:16 > Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps) > On 01.03.2018 16:39, Jesper Steen Møller wrote: > [...] >> |int numLetters = switch (day) { case MONDAY, F

Re: About supporting `var` of Java10+

My argument was not in relation to the JEP, but a Groovy user story, in relation to you saying, that I would not see a difference between def and var, apart from when assigning a value later on.  But assigning a value later on is _exactly_ what I am going to do when I use var - because otherwise

Re: About supporting `var` of Java10+

On Thu, Mar 8, 2018 at 9:53 PM, mg wrote: > Hi Paul, > > I would be interested to hear if you see some advantages of going down the > #define var def > route - apart from the obvious, that it is the easiest/fastest to > implement ? > I am not too worried about ease/speed of implementation but I

Re: Upcoming RC release for 2.5.0

Hi, The nextflow joint build is still using 2.5.0-beta-3. I think it should use the 2.5.0-SNAPSHOT, right? Cheers, Paolo On Tue, Mar 6, 2018 at 9:12 PM, Paolo Di Tommaso wrote: > I've double checked this and the compilation fails also locally using > `2.5.0-SNAPSHOT`. > > I've managed to com

Re: About supporting `var` of Java10+

Am 08.03.2018 um 12:45 schrieb mg: Maybe I am missing your point, but what I meant was: When I use var x = new Foo() I indicate that x will be reassigned further down in the scope, otherwise I use final x = new Foo() That's what I understood. But the later variant is not part of the JEP.

Re: About supporting `var` of Java10+

So you could sayvar var = new Varchar();-) Ursprüngliche Nachricht Von: Jesper Steen Møller Datum: 08.03.18 07:50 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: About supporting `var` of Java10+ Hi list It’s not a keyword in Java 10, it’s just a reserved identifier. In o

Re: About supporting `var` of Java10+

Hi Paul, I would be interested to hear if you see some advantages of going down the#define var defroute - apart from the obvious, that it is the easiest/fastest to implement ? Cheers,mg Ursprüngliche Nachricht Von: Paul King Datum: 08.03.18 12:26 (GMT+01:00) An: dev@groovy.ap

Re: About supporting `var` of Java10+

Maybe I am missing your point, but what I meant was: When I use var x = new Foo() I indicate that x will be reassigned further down in the scope, otherwise I use final x = new Foo() PS: I know all the Groovy samples in the documentation use def instead of final all the time, even though no reassig

Re: About supporting `var` of Java10+

What are peoples thoughts. Should we try to make "def" and "var" exactly aliases? Or almost? If we do, we need to add some info in the differences from Java section of the doco to explain the differences with Java's upcoming "var". If we don't, we need to articulate some good reasons for making the

Re: About supporting `var` of Java10+

Am 08.03.2018 um 09:44 schrieb mg: @unless you reassign, you would not notice the difference between current def and the Java var: 1) If I don't need to reassign, I would use final instead of var :-) 2) Supporting var for fields that get initialized during declaration, also would feel very Gro

Re: GPars and versions of Groovy

Hi, It depends which bit of GPars you are using. if you are using the CSP bit, sometimes known as JCSP, then this works on most JDK's back to 1.5 (I think). I have recompiled the code as each JDK came ut to the latest version and never had to chnage the underlying Java coding. I have yet to

Re: About supporting `var` of Java10+

@unless you reassign, you would not notice the difference between current def and the Java var:1) If I don't need to reassign, I would use final instead of var :-)2) Supporting var for fields that get initialized during declaration, also would feel very Groovy to me, although I personally would

Re: About supporting `var` of Java10+

Hi Jesper, We treat `var` as an alias of `def` with some limitations. Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html