Re: Distinguish foo.x and foo.getProperty("x") in call interceptor

On 13 Jan 2020, at 20.19, Marcin Zajączkowski wrote: > > Hi, > > TL;TR. How would be best to distinguish in Groovy 3 foo.x and > foo.getProperty("x") in a call (at the level of an interceptor for a > mocking system)? > I wonder if this is an intended change, or a result of some refactoring? S

Re: Potential XXE vulnerability in DomToGroovy

Hi Paul and Alexandru Thank you for the report, Alexandru. I agree with Paul's analysis: Users of DomToGroovy are by definition trusted parties, and the output should never be executed without human intervention. For example, DomToGroovy's escaping code can be circumvented in several ways, too

Re: About polish the generics type syntax for closure

If we know the desired target type of a closure, and the parameters are compatible, we could generate a Closure class which implements the applicable Functional Interface (such as Function, Predicate or whatever). For static Groovy, we could then skip the coercion. -Jesper > On 13 Feb 2019, at

Re: asset does not produce any output -am i missing something

Hi Krishnan, > On 10 Oct 2018, at 12.31, krishnandos...@gmail.com wrote: > > Hi the following lines of code does not produce anything > package com.mds2.automation > > import groovy.json.JsonSlurper > def jsonSlurper = new JsonSlurper() > def object1 = jsonSlurper.parseText('{"name" : "abc", "v

Re: Any macOS users around who can test groovyConsole on JDK10?

I couldn't get the URL (no login), but I tried the tip of master on Java 9 and 10, and the console started with both, using ./gradlew console from the repo root. Both threw a strange syntax error on start: > Task :groovy-console:console WARNING: An illegal reflective access operation has occurre

Re: Groovy 2.5 CliBuilder article (request for feedback)

Neat article, Remko -- and neat CLI support! Two very minor nitpicks: 1) The image for 'Script Annotations' is confusingly big/unwieldy, almost to the point of me nearly missing the joke ;-) 2) I'd use // 1, // 2, // 3 for pointing out individual lines in the examples. That way, you can still

Re: Groovy 3 release

On 27 May 2018, at 14.44, Daniel.Sun wrote: > > Native lambda is only available on master branch, and it is only be enabled > under static compilation. > I had a chance to examine the current implementation. It uses a LambdaMetafactory to bootstrap (i.e. generate inner class) access to the doC

Re: Groovy 3 release

> On 27 May 2018, at 20.25, Jesper Steen Møller wrote: > > On 27 May 2018, at 14.44, Daniel.Sun wrote: >> >> Native lambda is only available on master branch, and it is only be enabled >> under static compilation. >> > > I had a chance to examin

Re: Groovy 3 release

> On 27 May 2018, at 13.37, Daniel.Sun wrote: > >> 3) Java lambdas compile into Closures, which do not directly support > functional interfaces (so, in the examples shown for streams, proxies are > made) > > Groovy's lambda will be compiled into native lambda when static compilation > is enab

Re: Groovy 3 release

All of it is master with tests at the moment, as far as I've seen. There are a couple of caveats: 1) The default interfaces are implemented using traits, not as actual default methods on interfaces. 2) Method and constructor references are implemented as closures. 3) Java lambdas compile into Clo

Re: Performance of the compiler

Oh - I see now that this is implemented already (optimizationOptions w/asmResolvingin:true). Is there any reason this is not the default? Is it slower? Incorrect? -Jesper > On 24 May 2018, at 10.08, Jesper Steen Møller wrote: > > Interesting! So let me get this straight: Are we

Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]

ar? -Jesper > Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <mailto:jes...@selskabet.org>> a écrit : > > > On 23 May 2018, at 12.23, Russel Winder > <mailto:rus...@winder.org.uk>> wrote: > > > > On Wed, 2018-05-23 at 00:28 +1000, Paul King wro

Re: Performance of the compiler

Interesting! So let me get this straight: Are we using an actual "in-JVM" classloader to load classes examined by the Groovy Compiler itself? In the Eclipse Java compiler, we don't actually load the classes into the JVM, instead we have our own implementation of classpath traversal and read it us

Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]

> On 23 May 2018, at 12.23, Russel Winder wrote: > > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote: >> No plans to go to 18/19 model at this stage. >> >> If we push for an early 3.0, some of the breaking changes will have to be >> deferred. >> A very quick release after 3.0 could easily be

Re: 2.5.0-rc-3

And postpone module revamp? -Jesper > On 22 May 2018, at 13.27, Cédric Champeau wrote: > > I think we should slim down what Groovy 3 is, make it Parrot + JDK 8 > basically. > > Le mar. 22 mai 2018 à 13:22, Paul King > a écrit : > The question is really (most of) Pa

Re: Proposed Groovy 3.0 Scope

> On 22 May 2018, at 10.35, Paul King wrote: > > Nice list. The other thing worth adding somewhere is toolchain support for > the new Parser. > Tools like Groovydoc is needed I would say. We have some additional tools, > e.g. like Java2Groovy and others which we could then consider. > Oh, I

Proposed Groovy 3.0 Scope

Groovy 3.0 Scope (suggestion) TL;DR: I want to help develop Groovy 3.0, but I'm not sure how: It appears that there's little consensus around priorities and scope. I'm suggesting a structure for discussing scope and setting priorities. HTH. Introduction Several strands of Groovy development are g

Re: Java object conversion using ConfigSlurper

> On 16 May 2018, at 16.00, adithyank wrote: > > It works. But, If that `MyConfig` class has fields of `List` or `Map` types, > then it does not work. Actually it does work, too: ConfigObject co = new ConfigSlurper().parse(""" myownconfig { name = 'Threadpool' displayLabel = "Thread Po

Re: Java object conversion using ConfigSlurper

Hi Adithyank > On 16 May 2018, at 12.52, adithyank wrote: > > Hi Mario Garcia, > > Groovy already has Map coercion feature with which the methods of any class > can be delegated to the closures in Map. This uses `as` keyword. > > If we implement `asType(Class)` in `ConfigObject` (ConfigObject

Re: About raw string and enhanced try-with-resource

On 15 May 2018, at 12.31, Paolo Di Tommaso wrote: > > No. There's an important difference: raw strings do not escape any special > character ie. backlashes, dollars, back-ticks, etc. > Ah, I didn't actually realize that Groovy's current '''multiline''' style interpreted \ escapes. Haven't us

Re: About raw string and enhanced try-with-resource

> On 15 May 2018, at 12.14, Daniel.Sun wrote: > [..] >As you said, Groovy has many string(e.g. 'xxx', "xxx", '''xxx''', > """xxx""", /xxx/, $/xxx/$). but they can not cover the function of raw > string... > Isn't '''tripple-single-quoted''' basically the same as the raw string (only with a

Re: About creating instances of non-static inner classes with Java-Like syntax

Hi Remko, I'm so glad that somebody's used it (in Java). I've fixed an issue or two over in Eclipse JDT around this very construct (placement new) - I had to read the spec to find out how it was supposed to work... -Jesper > On 11 Apr 2018, at 16.01, Remko Popma wrote: > > Eric, > > Yes thi

Re: Await/ async?

I’ve come to like the pattern, too (having debugged too many rrc conditions in async code) However, I’m pretty sure it can be implemented as an AST transformation, with inspiration from EA’s EA Async project: https://github.com/electronicarts/ea-async (The implementation is left as an excercis

Re: About supporting `var` of Java10+

Yes, I see it now. I implemented 'var' for Eclipse's Java compiler, but did it without changing the grammar, so when I saw you'd changed the grammar, I wrongly assumed you hadn't thought of it. -Jesper

Re: About supporting `var` of Java10+

Hi list It’s not a keyword in Java 10, it’s just a reserved identifier. In other words, “int var = 10;” is still legal. I’m thinking we should remain as conservative as Java in those matters. -Jesper > On 8 Mar 2018, at 02.23, MG wrote: > > Hi Daniel, > > I agree that it does not make much

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

ax is crystalized first! > > But yeah, I like the idea of supporting it. > (and we could potentially support it before the Java version containing it is > released) > > Guillaume > > > On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller <mailto:jes...

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

Hi MG > On 1 Mar 2018, at 20.56, MG wrote: > > You mean http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html > ? > It's been split up into JEP 325 (switch expr) and http://openjdk.java.net/jeps/305

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

Hi list Java 11 (or perhaps 12) might see a new functionality known as switch expressions (https://bugs.openjdk.java.net/browse/JDK-8192963 ). While the current Groovy implicit return functionality works with the switch statement as-is, the swi

Re: [GEP] Concatenative Method Calls

Interesting proposal and discussion! As somebody who routinely work in both Java, Groovy, TypeScript/ES6 and C#, I find this syntactically too close too arrow functions/lambdas, in other words, they may confuse a lot of readers. As for the semantic content: I realize that Groovy goes a long way

Re: About the callable native lambda

Hi again > On 1 Feb 2018, at 13.48, Jochen Theodorou wrote: > > [...] >> For static compilation, r1() and r2() should work IMHO, and r3() should be >> rejected. This shouldn't surprise anyone, I think. > > you mean because the m has a return value and r3() is void? That is currently > passin

Re: About the callable native lambda

(Sorry, first version went out too soon, thanks to the silly, silly Touch Bar) > On 31 Jan 2018, at 23.01, MG wrote: > > Hi Jesper, > > seen from a Groovy user perspective your proposal seems to make sense to me. > (I would at the same time hope you do not dent Daniel Sun's enthusiasm too > mu

Re: About the callable native lambda

oice in this regard. Default behavior could also be made overridable by a > class annotation (then it would become the programmer's responsibility, to > make sure least surprise is not violated). > Without that the question to me is: Would choosing "fallback if obj.call >

Re: About the callable native lambda

Hi list FYI: This turned into a discussion of the feature itself, on the GitHub commit thread. Basically, I'm proposing changing what "obj(params...)" means: - Non-SAM types: obj(params...) becomes obj.call(params...) - SAM types: obj(params...) becomes obj.(params...) - perhaps only as a fal

Re: About the callable native lambda

Hi Daniel I very much recommend going with option 2: It could and should work for any functional interface, not just the ones implemented in Groovy. Ideally, there would be no difference between a "Java lambda" and a "Groovy lambda" -Jesper > On 30 Jan 2018, at 01.14, Daniel Sun wrote: > > H

Re: About the native-lambda branch

Hi Daniel > On 15 Jan 2018, at 10.53, Daniel Sun wrote: > > Hi Jochen, > > `ArrayIndexOutOfBoundsException` is fixed. I encounter another > problem(i.e. How to load arguments according to some specified order): I > want to load local variables[1] according to the order in which the local >

Re: About the native-lambda branch

Hi Jochen and Daniel > On 12 Jan 2018, at 12.48, Jochen Theodorou wrote: > > > > Am 12.01.2018 um 04:05 schrieb Daniel Sun: >> Hi Nathan, >>> What's will the differences be between closures and lambdas? >> The native lambda will have better performance than closure. In addition, >> native lamb

Re: About the native lambda

> On 22 Dec 2017, at 10.48, Daniel.Sun wrote: > > The problem I am trying to resolve is how to get the method's name > and descriptor? [2] It seems the type flow analysis have to rely on the > existing static compilation... > There is no short cut possible here: You need full static anal

Re: How to find out the names of variables used in a groovy expression

HI Greg, Note: This list is primarily for developers and maintainers of the Groovy project, not for how to use Groovy. You could try us...@groovy.apache.org instead. As for your question, which is admittedly borderline: 1) At compile time (i.e. in a macro or AST transformer), this should be doab

Re: New syntax explosion

Hi List > On 5 Oct 2017, at 20.01, eric.mil...@thomsonreuters.com wrote: > > [...] > `a??.b.c.` is just `a?.b?.c` > Are there any cases where a?.b.c would every make sense -- if a is null, then the expression would throw anyway, wouldn't it? Or is there some dynamic mixin case I'm not takin

Re: [VOTE] Release Apache Groovy 2.6.0-alpha-1

It's two problems in one. A) The code generation itself is not quite so bad as you might think, especially if we for a moment ignore serializable lambdas. For instance, here's how Eclipse's JDT does it: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/ecli

Re: Towards a better compiler

Hi list > On 21 Apr 2017, at 14.33, Andres Almiray wrote: > > I had a brief chat with Jochen a few days ago regarding this topic. > > Until now the usage of a Set or some other data structure was not really that > important. > If Groovy switches to a SortedSet then results may be more predicta

Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

> On 7 Feb 2017, at 16.27, Daniel Sun wrote: > To fully support *real* lambda expression, (to be honest)currently I > have no idea how to generate bytecode for it. In addition, supporting Static > Compilation will be another big work… > > A real lambda expression is implemented in Java a

Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)

(changing the subject so we don't disrupt the main discussion) Not quite 😔 The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while bac

Re: [VOTE] Apache Groovy Roadmap

Well, I didn't see many actually object to the contents or order that you suggested, but primarily the numbering. I'll give it another go. The vote thread seemed to raise three issues: 1) Whether or not to provide the parrot parser as a standalone option ASAP (this is actually quite a bit of wor

Re: [VOTE] Apache Groovy Roadmap

Hi list > On 2 Feb 2017, at 11.58, Paul King wrote: > > This thread has kind of gone into debate mode but I guess for the > record I would be -1 on any releases having parrot that weren't marked > as "experimental" or "incubating" until we thrash out future plans for > dealing with Java 8 featur

Re: release process

> On 31 Jan 2017, at 09.31, Guillaume Laforge wrote: > > And speaking of this pull request: the Antlr v4 JARs are built against Java 7 > / JDK 7? > Antlr4 runtime jars are Java6 (classfile version 50). I didn't try dropping down the parser down to 1.6, since I lack a 1.6 older JVMs on my curr

Re: [VOTE] Apache Groovy Roadmap

On 31 Jan 2017, at 10.46, Jochen Theodorou wrote: > > > On 31.01.2017 09:37, Cédric Champeau wrote: >> >> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7 >> - Groovy 3.0: integrate 3 and 5. The only version with necessary >> breaking changes (we have no choice here) > > If you

Re: release process

> On 30 Jan 2017, at 21.32, Guillaume Laforge wrote: > > That's indeed another approach. > But that would mean two close major releases with breaking changes. Do you > think it'd be acceptable? > If the testing is suffciently solid, how would shipping Groovy with Parrot (for Java 7) a breaki

New Groovy parser now on JDK 1.7

Hi List FWIW, I took the liberty of vandalising the Antlr4 'parrot' parser from its Java 8 style into Java 7. The result is found in: https://github.com/apache/groovy/pull/485 Travis tested using JDK8 and passed, my own build on Java 7 (On OS X) passes too. This would make the parser ready for

Re: About the "implies" operator(GROOVY-2576)

Hi Jochen and Daniel Not entirely correct: There are some ways to extend a grammar with new opperators, as demonstrated in http://stackoverflow.com/questions/29894457/dynamic-operator-tokens-in-antlr4 However, this

Re: release process

But - I recognise that the Antlr4 parser AST building looks really neat in Java 8, but easthetics aside, wouldn’t it we a relatively easy task to port back to Java 7? -Jesper > On 24 Jan 2017, at 16.59, Jochen Theodorou wrote: > > > > On 24.01.2017 15:51, Cédric Champeau wrote: >> The main

Re: SAM type closure coercion

A word of warning: Solving this according to the spec is a hard problem (speaking from experience with the Eclipse compiler when supporting Java 8), especially if you add parameterized types to the equation. To quote the JLS: "In JSR 335, the greatest complexity lurked in the interaction of impl

Re: About actor syntax for Groovy 3

But Wouldn’t << be a natural choice which would work today? -Jesper > On 7 Jan 2017, at 18.16, Daniel Sun wrote: > > Hi all, > > As we all know, GPars is awesome in concurrency programming. How about > introducing a new syntax for GPars's > actor(http://www.gpars.org/guide/guide/actors.h

Re: Lambda expression for Groovy 3

Hi Daniel Be careful with that approach, as it won’t work for static methods — leading to very different semantics for the two languages. Also, you won’t be able to support constructor references without some new AST construct, I guess. -Jesper > On 19. okt. 2016, at 12.23, daniel_sun wrote:

Re: Lambda expression for Groovy 3

"Real lambdas" with the full invokedynamic treatment is a big job, and requires static type inference. Given that Groovy can already coerce closures into functional interfaces (dynamically), we could implement the whole metafactory-stuff with the static compilation, and as a separate effort, rig

Re: The long path to a new MOP

Hi all, > On 7. aug. 2016, at 13.49, Jochen Theodorou wrote: > Since this will take several normal releases I think just using a branch will > not do here. Because keeping them just in sync will probably take up most of > the time I would normally use to implement this. So I was wondering... w

Re: http://ci.groovy-lang.org/ - "The TeamCity license will expire in 10 days."

FWIW, it was quite easy to set up CircleCI. -Jesper > On 16. mar. 2016, at 20.04, Pascal Schumacher > wrote: > > Hello everybody, > > the TeamCity license of http://ci.groovy-lang.org/ will expire soon. > > - Pascal

Groovy grammar ambiguity / question

Hi List I’ve yet to fully understand the rules behind the parenthesis-less method invocation syntax. Basically, it seems that while parenthesis-less method invocation (“command style”) can sometimes be used as an expression, it’s not universally so. I’d like to understand whether this is a mer

Re: More Antlr4-based Groovy parser status update

reat. > > Guillaume > > On Sun, Feb 28, 2016 at 12:55 PM, Jesper Steen Møller <mailto:jes...@selskabet.org>> wrote: > Hi Groovy-Dev > > Here’s another update on the progress on the Antlr4 parser, as maintained on > https://github.com/jespersm/groovy.git > &

Re: Progress on the Antlr4-based parser

> On 7. mar. 2016, at 13.52, Jochen Theodorou wrote: > > hehe... outer.super() give me a real WTF moment here ;) I have no idea what > it does... even fantasy fails miserably here. It is actually more important > to keep the grammar maintainable, then to add every obscure feature Java has > t

Re: Progress on the Antlr4-based parser

Hi Blackdrag On 7. mar. 2016, at 10.02, Jochen Theodorou wrote: > > On 07.03.2016 07:48, Jesper Steen Møller wrote: > [...] >> >> So you can help me with a couple of answers: >> >> * Is it a goal to close the gap to Java’s more trickier syntax, such >

Progress on the Antlr4-based parser

Hi again Groovy-Dev Here’s another update on the progress on the Antlr4 parser. I’m still exploring the limitations of the parser, partly by inspection and comparison with the Groovy documentation, and partly by experimentation (letting it loose on all the *.groovy files in the repository) Sin

Re: Inner traits?

Hi Jochen > On 29. feb. 2016, at 12.05, Jochen Theodorou wrote: > On 29.02.2016 11:52, Jesper Steen Møller wrote: >> Those semantics should be easy enough to cope with, if only the grammar (and >> taste!) would allow it. > > Why does the grammar not allow it? The gr

Re: More Antlr4-based Groovy parser status update

Hi Jochen > On 29. feb. 2016, at 11.39, Jochen Theodorou wrote: > > On 28.02.2016 12:55, Jesper Steen Møller wrote: > [...] >> * Memory: Is this an issue I should be focusing on — and is there a >>test to baseline against? > > no test you can baseline against

Re: Inner traits?

Hi Jochen and Henry > On 29. feb. 2016, at 11.29, Jochen Theodorou wrote: > > On 27.02.2016 19:29, Christophe Henry wrote: > [...] >> public class CustomApplication extends Application >> { >> private static instance […] >> public ContextgetApplicationContext(){return >> instance.ap

Re: More Antlr4-based Groovy parser status update

> Concerning the ASTBuilder to Java conversion, there is a pull request with > this at the old repo https://github.com/groovy/groovy-core/pull/513 > <https://github.com/groovy/groovy-core/pull/513> > > Cheers, > Pascal > > Am 28.02.2016 um 12:55 schrieb Jesper Steen

Re: More Antlr4-based Groovy parser status update

Just a clarification: I wrote: > I’ve discovered a small issue with unary syntax. Currently, nested unary > expressions are not supported without parenthesis: Try e.g. - -1 or + -1. Is > this intentional, or just an artifact of the precedence-refactored Java > grammar? > By “currently”, I mea

More Antlr4-based Groovy parser status update

Hi Groovy-Dev Here’s another update on the progress on the Antlr4 parser, as maintained on https://github.com/jespersm/groovy.git (in the antlr4 branch). To play with it, try: $ git clone -b antlr4 https://jespe...@github.com/jespersm/groovy.git $ cd groovy $ gradle -PuseAntlr4=true console I’v

Re: [GitHub] groovy pull request: Link to MrHaki's blog in TupleConstructor jav...

Also, people these days would usually consult documentation online sources than bother with locating any local javadoc/groovydoc documentation sources, hidden away in some local m2 repo cache (or is that just me?). That’d make a stale link somewhat less likely, outweighed by the goodness of Groovy

Re: Antlr4-based Groovy parser status update

> to minimize the risks. > > 2016-02-24 12:35 GMT+01:00 Paul King <mailto:pa...@asert.com.au>>: > Spock for testing is by no means a show stopper! > > On Wed, Feb 24, 2016 at 6:46 PM, Jesper Steen Møller > mailto:jes...@selskabet.org>> wrote: > > > >

Re: Antlr4-based Groovy parser status update

grammar and the AST building done right. The current tests use Spock. Is that out of the question for the main Groovy build? I lve Spock, but I realise we have to keep the number of dependencies down. -Jesper > > On Wed, Feb 24, 2016 at 1:14 AM, Jesper Steen Møller <mailto:jes.

Antlr4-based Groovy parser status update

Hi Groovy-dev I’ve found some time to work on the Antlr4 parser and fixed some minor tasks there: * Fix grammar for several statement sequences, where NL or semicolon was not required (added negative test cases) * Remove non-reentrant static state in ASTBuilder * Added syntax error handling to

Re: Groovy DevCon in Copenhagen?

On 2. feb. 2016, at 12.55, Guillaume Laforge wrote: > On Tue, Feb 2, 2016 at 12:52 PM, Jochen Theodorou > wrote: > > On 02.02.2016 12 :46, Guillaume Laforge wrote: > > It would be nice to see some of our recent committers, like John, Shil, > and older ones as well :-)

Re: Groovy 3.0

Hi list On 31.01.2016 21:29, Thibault Kruse wrote: > Are Antlr 4 and Jva 8 syntax linked somethow, meaning is there a hard > problem describing certain java8 features using whatever antlr version > is used right now? I’ve decided to give the Antlr4 task another go. I had some major trouble getti