RE: Groovy as expression parser

[Winnebeck, Jason]

Yep, in this case, it is true. We used to use a rules engine, IBM JRules, we 
retired it years ago and converted all of the rules into Groovy. It cost 
6-figures annual support, forced us to use Oracle Weblogic, was extremely slow, 
took a huge effort to map the data model into it so you could write 
"English-like statements with it" and the whole "point" of it is that 
non-developers could theoretically update it. Except programming is not hard 
because learning Java/Groovy syntax is hard. The hard part is figuring out what 
to do, regression testing, making it perform well, etc. So ultimately the 
business farmed all of the edits out to the programmers, so instead of 
programming in code, we program in some drag and drop interface with a 
proprietary Eclipse plugin that only ran in an obsolete version of Eclipse and 
it took 30 minutes to "compile". It's been a few years, but when I looked at 
things like Drools, which looks closest to JRules I didn't see a drastic 
difference to the architecture. In fact, that was the reason why we introduced 
Groovy into the engine, now we have 1000s of Groovy files using STC for 
performance and now rule engine times are in milliseconds instead of seconds 
execution times. And we have a DSL syntax created that emulated the same 
structure of the rules so we could largely copy/paste the code or generated 
code into when {} then {} clauses. Except now it's all "real" code meaning we 
get compile-time safety, find usages in IDE, refactoring, debugger, etc.

But, in the end, we still needed to have some data tables outside of the 
structure, that the non-technical business stakeholders can and do maintain. 
But there is some idea to be able to add simple expressions to that. Not to go 
as far as a Drools decision table. But maybe. Even if we end up "re-inventing 
the wheel" a little bit, we're still in a much better place.

I have had the thought of going all out and being able to upload entire Groovy 
files as rules, then it really is like a rules engine. But it comes back to the 
same problem - who is going to be editing this code, and this code is not going 
to be in the IDE environment, using version control, etc. So, I expect this 
still to be quite simple. Hence the choice of SPEL as alternative. But Groovy 
has option of getting arbitrary complex, if we wish. I especially like creating 
DSLs meant to be used with command chains and it would be a good ability. Based 
on several responses here and no explicit warning from Jochen, it sounds like 
we're not "abusing" Groovy to compile perhaps 100s of very small scripts. While 
they can change on demand, it's likely not more than once a week. So 
compilation time is not a concern. It's only a concern of metaspace overhead 
(we are still on Java 8... but we do have a big heap) and execution performance.

Jason



Sensitivity: Internal
From: Edmond Kemokai 
Sent: Tuesday, October 27, 2020 6:09 PM
To: users@groovy.apache.org
Subject: Re: Groovy as expression parser

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

What you're building is a decision table, a common component in business 
applications. I am not familiar with SPEL but it sounds like it will probably 
serve your needs without the need for a full fledged programming environment.

You could also look into the various rules engines available for the JVM that 
address the same problem.
https://www.baeldung.com/java-rule-engines

Regards
Edmond

RE: Groovy as expression parser

[Winnebeck, Jason]

Thanks Edmond for the feedback, and Alessio as well who replied also.

I know all of the expressions at once, although they can change as the 
application runs, so it is possible to combine them into one class, but I would 
then be constructing source code myself, which is a little bit of a concern, 
and having to call methods dynamically via reflection (rather than through an 
interface like I’d do if each one turned into a Closure), which ups the 
complexity compared to SPEL. The expressions may also repeat, which is 
something I should consider (I know some of the Groovy scripting utility 
classes will “cache” the code and handle this).

The data is a set of business rules tables, today we have something like this, 
let’s say I have a store selling mobile phones and I’m offering conditional 
discounts that can change on the fly.

Attribute, Low_value, high_value, discount%
Vendor, Apple, , 25%
Vendor, Samsung, , 20%
Total_price, 500, 1000, 10%

You can see such a table is awkward (because it represents the expressions 
‘vendor  == Apple’ gives 25% discount and ‘price >= 500 && price <= 1000’ gives 
10% discount in the same format). I’m very limited to the conditions I add, and 
if I want to add different types of conditions, such as don’t allow selling 
Apple and Samsung phone on same mobile plan, it can get very complicated (many 
columns) to impossible very quick. We’re not quite to the point where we want 
to build some dedicated microservice or ability to hotswap JARs on the fly yet 
to allow changing this quickly without redeploy, but beyond the point where 
straight tables can get us. So I am looking to see if we can use a simple 
expression language. And we use Groovy very extensively today, as well as 
Spring.

I think the conclusion is that I should just test the performance to see how it 
works out and how well it will scale over time. There is obvious benefits in 
that Groovy allows “unlimited” potential compared to SPEL. But “unlimited” 
could get us into trouble because I don’t want to be making REST API calls and 
defining classes in an expression 😊, so do I really need anything more than 
what SPEL gives to me. I know in Groovy I do like the possibility to consider 
command chains that read better than SPEL: “when vendor is ‘Apple’” -> 
when(vendor).is(‘Apple’)

When I think about SPEL it actually should be efficient, too. I realize 
template systems like Thymeleaf are based on this and evaluate many expressions 
to render a single page. Likewise Groovy server pages / Grails does it not do a 
similar thing? But maybe all of those closures get mapped to a single class 
like JSP does.

Jason Winnebeck



Sensitivity: Internal
From: Edmond Kemokai 
Sent: Tuesday, October 27, 2020 11:08 AM
To: users@groovy.apache.org
Subject: Re: Groovy as expression parser

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Jason,

I am working on a product that uses Groovy as a dynamic scripting language 
within a Java web app and have been contending with this concern as well.

Some things to consider:

Is it possible to consolidate these 100s of expressions into a fully qualified 
named class?
With this approach you could then create a singleton of such a class and retain 
that in memory via the java web app session. You could then map the expression 
evaluation to some sort of naming scheme (basically a bunch of if/else blocks), 
or just map each expression to a unique function.

This of course takes away some of the flexibility of being able to run 
arbitrary code.

As to the overhead of constantly compiling these expressions, I can't speak to 
actual numbers but there is definitely an overhead, you'll probably need to do 
your own jvm performance profiling to determine whether it is an actual problem.

In my case I am using the java scripting API to evaluate Groovy code, with that 
API it is possible to obtain a compiled instance of the code ( 
javax.script.CompiledScript ) that can be rerun multiple times without 
recompiling. This is an alternative way to address compilation overhead.

Hope this helps.

Regards
Edmond

Groovy as expression parser

[Winnebeck, Jason]

I know technically, Groovy can compile scripts which are just predicate 
expressions. For example, "age > 20" or "product.price > 20 || product.name == 
'Strawberry'". But is Groovy a good choice for this, if I have many expressions 
(100s), and will be executing most of those on every request in a web 
application / REST API? The alternative I am considering is Spring Expression 
Language (SPEL), which can compile these simple expressions as well. From what 
I understand Groovy is creating a new class from each expression/script, so 
that overhead unreasonable compared to SPEL? Maybe Groovy is too "heavy" for 
this simple use? We use both Spring and Groovy in the application now, so 
there's no concern about increase in dependency tree / app size.

Jason Winnebeck


Sensitivity: Internal

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: groovysh and long input

[Winnebeck, Jason]

I'd be curious to know the conclusion on this, it sounds like a scalability 
issue in the parser. I've seen similar behavior in our application, but I've 
not had time to isolate it further. We're still stuck on Groovy 2 because we're 
unable to compile on Groovy 3 because I haven't been able to give the parser 
enough RAM or CPU time. A few hundred MB is OK to compile in Groovy 2 but even 
with multi-GB heap sizes result in out of memory exception in Groovy 3 and 
minutes long compile times.

Jason Winnebeck



Sensitivity: Internal
From: Stephen Mallette 
Sent: Friday, October 16, 2020 2:58 PM
To: users@groovy.apache.org
Subject: groovysh and long input

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hello,

I happened to be testing some issues related to this pull request I submitted 
the other day:

https://github.com/apache/groovy/pull/1405

In testing between groovy 2.5.x and 3.x I've noticed a considerable performance 
difference when pasting long multi-lined scripts. 2.5.x is quite quick to 
accept the input whereas 3.x seems to slow more and more as additional lines 
are consumed. While I did more complex tests trying to get to the bottom of the 
problem, it's fairly easy to recreate with a simple addition script:

1 + 10 +
1 + 10 +
1 + 10 +
1 + 10 +
1 + 10 +
... repeated a bunch of times and then ended with
1

copy that out of your text editor and just paste it into both versions of 
groovsh and see the difference. I've found 500 lines demonstrates it well but 
you could probably get away with less and still see the difference of 
evaluation at play.

I tried to do some profiling to try to isolate the problem myself, but things 
got a little too deep into antlr4 for me and I got lost. Does anyone have any 
ideas as to what might be different for 3.x?

RE: Groovy 3 OWNER_FIRST closure passed to method with resolve strategy DELEGATE_FIRST

[Winnebeck, Jason]

I did some research with Groovy 2.5 that I happened to have installed on 
path... It seems that CompileStatic bakes in the resolve strategy at the time 
the closure is created. So my 2.4 project, assuming 2.5 works the same as 2.4, 
is operating as OWNER_FIRST, even though it's passed to with (unless the 
closure was compiled in dynamic mode).

It seems for me, the proper solution then is to not use "with" but instead 
create a new variation of "with" that works with OWNER_FIRST and call that 
instead. It seems also that this message might be better as a warning than an 
error, or to have a flag have it be a warning, since it looks like it can work 
as the old code in runtime, although I agree, any new code written should not 
have this pattern because it is so misleading.

Jason



Sensitivity: Internal
From: Winnebeck, Jason 
Sent: Tuesday, August 18, 2020 12:22 AM
To: users@groovy.apache.org
Subject: Groovy 3 OWNER_FIRST closure passed to method with resolve strategy 
DELEGATE_FIRST

I'm upgrading a project from Groovy 2.4.19 to 3.0.5 with 100s of classes almost 
all @CompileStatic code on JDK 8. Upon upgrading I get compiler errors about 
static type checker knowing or not knowing anymore of objects, which is par for 
the course for any Groovy upgrade. But most of the errors I get are this:

Closure parameter with resolve strategy OWNER_FIRST passed to method with 
resolve strategy DELEGATE_FIRST

The pattern that I am using is having a method that takes a Closure, and passes 
it to Object.with:

void run(@DelegatesTo(X) Closure closure) {
  println "I'm running!"
  something.with(closure)
}

run { println prop }

So I know what OWNER_FIRST and DELEGATE_FIRST mean. And I see that the default 
in @DelegatesTo (or no annotation presumably) is OWNER_FIRST, and with clones 
the closure and sets its resolve strategy to DELEGATE_FIRST.

I can't find documentation on this message. Does the message being an error 
imply that the resolve strategy on a closure is "baked in" in CompileStatic? 
Did that change since 2.4? What is the best practice solution?

Other notes:

  1.  I build with IDEA and the default 700mb heap was not enough to build, I 
needed 5GB heap to build without OutOfMemoryError is that expected?
  2.  I'm trying to upgrade from 2.4.19 because I encountered a bug in static 
compile, in an expression x.value = someEnum, there is x.setValue(boolean) and 
x.setValue(String). 90% of the time the static compiler picks the 
setValue(String) for all such call sites in a build, 10% of the time it picks 
setValue(boolean) for all such call sites. I didn't receive any compiler errors 
on that expression as I'd expect it to be ambiguous (or at least pick same each 
time), is that expected to fail compile in Groovy 3?

Thanks,

Jason Winnebeck


Sensitivity: Internal
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Groovy 3 OWNER_FIRST closure passed to method with resolve strategy DELEGATE_FIRST

[Winnebeck, Jason]

I'm upgrading a project from Groovy 2.4.19 to 3.0.5 with 100s of classes almost 
all @CompileStatic code on JDK 8. Upon upgrading I get compiler errors about 
static type checker knowing or not knowing anymore of objects, which is par for 
the course for any Groovy upgrade. But most of the errors I get are this:

Closure parameter with resolve strategy OWNER_FIRST passed to method with 
resolve strategy DELEGATE_FIRST

The pattern that I am using is having a method that takes a Closure, and passes 
it to Object.with:

void run(@DelegatesTo(X) Closure closure) {
  println "I'm running!"
  something.with(closure)
}

run { println prop }

So I know what OWNER_FIRST and DELEGATE_FIRST mean. And I see that the default 
in @DelegatesTo (or no annotation presumably) is OWNER_FIRST, and with clones 
the closure and sets its resolve strategy to DELEGATE_FIRST.

I can't find documentation on this message. Does the message being an error 
imply that the resolve strategy on a closure is "baked in" in CompileStatic? 
Did that change since 2.4? What is the best practice solution?

Other notes:

  1.  I build with IDEA and the default 700mb heap was not enough to build, I 
needed 5GB heap to build without OutOfMemoryError is that expected?
  2.  I'm trying to upgrade from 2.4.19 because I encountered a bug in static 
compile, in an expression x.value = someEnum, there is x.setValue(boolean) and 
x.setValue(String). 90% of the time the static compiler picks the 
setValue(String) for all such call sites in a build, 10% of the time it picks 
setValue(boolean) for all such call sites. I didn't receive any compiler errors 
on that expression as I'd expect it to be ambiguous (or at least pick same each 
time), is that expected to fail compile in Groovy 3?

Thanks,

Jason Winnebeck


Sensitivity: Internal

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: What projects use Groovy as its main development language ?

[Winnebeck, Jason]

Our team introduced Groovy into the main sales quoting system used at the 
company I work for. The framework itself is mostly in Java, but in all places 
we support Groovy as a first-class choice (joint compilation mode) and allow 
developers to pick either language based on preference and appropriate tool. We 
use Groovy almost exclusively in the static compile mode, for performance 
reasons. The code implementing the REST APIs and consuming SOAP and REST APIs 
are the places where we use dynamic Groovy, because dynamic Groovy works so 
much better in webservices. To be honest though, since Java 8, we have been 
using Groovy less because the streams API gives us something close to one of 
the main benefits we got from Groovy (through findAll, collect, take, etc.). 
Now Groovy is mostly syntax sugar for us with Java 8+ lambdas around. Java 
performs better, debugs better, compiles faster, works better with hotswapping 
than Groovy does, so we tend to favor Java now unless we really itch for Groovy 
features in a file. In our main project we have over 1100 .groovy source files. 
We have one other project mostly using Groovy, and a few others using Groovy in 
a lesser manner. And we use Groovy extensively in any utility/script/one-off 
type scenario (i.e. if I need to write a script to do some JMX operations or 
parse log files or script some SSH operations, etc.). We are still using Groovy 
2.4 but I am very curious to see if Groovy 3 and/or indy on modern JVM will 
help considerably with the performance reason to prefer Java. In particular we 
use a very high amount of closures, which still have a penalty to coerce into 
functional interfaces even in static groovy 2.4 and in GroovyObject 
constructor, but supposedly in Groovy 3 this might be better as I hear closures 
can be replaced with lambdas. Also besides the performance, lambdas fare much 
better for hotswap than Closures (Groovy will "renumber" all of the Closures if 
you add one, which destroys hotswap).

Jason


Sensitivity: Internal

-Original Message-
From: MG  
Sent: Friday, June 26, 2020 6:24 PM
To: users@groovy.apache.org
Subject: What projects use Groovy as its main development language ?

A quick survey: Who on this mailing list works on or knows of a project where 
Groovy is the main language of development, i.e. it is not used as "just" a 
script or DSL language in addition to e.g. Java ?
If possible name the company/country/project and give some impression of the 
size of the project (lines of code, # of people working on it, etc), timeframe 
of development, and whether it is os or commercial (or both) G-)

Thanks in advance,
cheers,
mg

RE: Is there a way for an object to know it _enters_ a try-with-resource block?

[Winnebeck, Jason]

I would not be too concerned about having to create a new object. I've heard 
that modern JVMs are really good at detecting temporary objects that don't 
escape a method and turning them into stack objects.

So I would do something like this (let's assume you really don't want to create 
new Foo):

class FooSession implements Closeable {
  private final Foo foo
  FooSession(Foo foo) { this.foo = foo; foo.start(); }
  void close() { foo.close() }
}

def a = new Foo()
try(new FooSession(a)) { println "1" }

There is actually precedence for this in other languages: in C++ with RAII 
concept one uses the "lock" object pattern to ensure unlocking... as a way to 
get a kind of forced "finally" concept.

However, this still doesn't force the user to use the session. If you want to 
do that, and you can modify foo, why don't you add a start method to Foo?

class Foo { //notice Foo is NOT implements Closeable
  Closeable start() { println "Hi"; new FooSession(this); }
  void close() { println "Bye" }
}

def x = new Foo()
try (x.start()) { println "1" }

Of course, you could also have the start method take a closure -- if you don't 
care about seeing try-with-resources directly, then you can make the same 
pattern:

x.start { println "1" }

Jason


Sensitivity: Internal

-Original Message-
From: o...@ocs.cz  
Sent: Monday, June 1, 2020 8:43 PM
To: users@groovy.apache.org
Subject: Re: Is there a way for an object to know it _enters_ a 
try-with-resource block?

P.S. Or, it would be quite sufficient to be able to get the list of the 
closeables inside of the try-with-resource. I mean something like

===
static List somethingSmart() { ... }
...
def a=new Foo(),b=new Foo(),c=new Foo()
try (a) {
  assert somethingSmart()==[a]
}
try (b,c) {
  assert somethingSmart()==[b,c]
}
===

Does Java or Groovy allow to write such kind of “somethingSmart”? How?

Thanks,
OC
  

> On 2. 6. 2020, at 2:28 AM, o...@ocs.cz wrote:
> 
> Is there some trick which would, with a proper replacement of ???, ensure 
> that the following code:
> 
> ===
> class Foo {
>  void ???() { println "Hi" }
>  void close() { println "Bye" }
> }
> ...
> def foo=new Foo()
> println "1"
> try (foo) { println "2" }
> println "3"
> try (foo) { println "4" }
> println "5"
> ===
> 
> prints out 1,Hi,2,Bye,3,Hi,4,Bye,5?
> 
> I'd rather like not to create a new foo object for each try block (which of 
> course would be sorta-solution); it would be _considerably_ more convenient 
> to reuse it -- if there was a way for that to know it enters the try block.
> 
> Thanks!
> OC
> 

RE: [ANNOUNCE] Apache Groovy 3.0.0 released

[Winnebeck, Jason]

That’s what I was looking for. I looked on the download page. What I didn’t 
realize is the Release Notes on the left navigation on the page was not part of 
the main page but goes to a separate page. I think a link to release notes on 
download page would be useful as well.

Jason

From: Paul King 
Sent: Monday, February 10, 2020 4:50 PM
To: users@groovy.apache.org
Subject: Re: [ANNOUNCE] Apache Groovy 3.0.0 released

Hi Jason,

That changelog combines the changes in all RCs, betas etc.

You might also like:
http://groovy-lang.org/releasenotes/groovy-3.0.html<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy-lang.org%2Freleasenotes%2Fgroovy-3.0.html&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C81951fcb609a43e9196708d7ae7335b2%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C637169682164346086&sdata=22rRIk24A3pj8VZ2Jz35KlIK0o9Ej5sbWsw7iKWwsik%3D&reserved=0>

Cheers, Paul.

On Tue, Feb 11, 2020 at 1:39 AM Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>> wrote:
Amazing news! Is there a page with a summary of changes from 2.x series along 
with any compatibility/migration notes? I see the changelog for 
3.0.0<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy-lang.org%2Fchangelogs%2Fchangelog-3.0.0.html&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C81951fcb609a43e9196708d7ae7335b2%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C637169682164351072&sdata=hUtCi8vTfydgHzGNNBLIcbXnstR2K2%2F8JFLTlyAIzFE%3D&reserved=0>
 but not sure if that is from RC3 or from something else.

Jason

From: Paolo Di Tommaso 
mailto:paolo.ditomm...@gmail.com>>
Sent: Monday, February 10, 2020 9:56 AM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Re: [ANNOUNCE] Apache Groovy 3.0.0 released

Congrats, folks!! 👏b4c1b0ed4👏

On Mon, Feb 10, 2020 at 3:46 PM Søren Berg Glasius 
mailto:soe...@glasius.dk>> wrote:
Awesome. A new Era has begun 😊
Med venlig hilsen / Best regards

Søren Berg Glasius

Sent from my phone, thus brief

On Mon, Feb 10, 2020, 14:06 Paul King 
mailto:pa...@apache.org>> wrote:
Dear community,

The Apache Groovy team is pleased to announce version 3.0.0 of Apache Groovy.
Apache Groovy is a multi-faceted programming language for the JVM.
Further details can be found at the 
https://groovy.apache.org<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroovy.apache.org%2F&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C81951fcb609a43e9196708d7ae7335b2%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C637169682164356063&sdata=2FEoIWBrufYosB8Wa5av0K69NHkBW3ttKYLjexTreuc%3D&reserved=0>
 website.

We are sure you'll enjoy the features in this new version of Groovy.
Your feedback on any unintentional glitches is welcome.

This release includes 15 bug fixes/improvements since RC3 as outlined
in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12345566<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D12318123%26version%3D12345566&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C81951fcb609a43e9196708d7ae7335b2%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C637169682164361053&sdata=vaVq7FvpjD6p4e5bqhXkk8fgy9h9j6jlnptsJv%2FRkSY%3D&reserved=0>
(There are over 500 new features, improvements and bug fixes since Groovy 2.5!)

Sources, convenience binaries, downloadable documentation and an SDK
bundle can be found at: 
https://groovy.apache.org/download.html<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroovy.apache.org%2Fdownload.html&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C81951fcb609a43e9196708d7ae7335b2%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C637169682164366044&sdata=64InNF4nDqFxHVG%2Bc3M2vMXKFINLt96%2BxNrr2cfS%2B7w%3D&reserved=0>
We recommend you verify your installation using the information on that page.

Jars are also available within the major binary repositories.

We welcome your help and feedback and in particular want to thank
everyone who contributed to this release. We value all forms of
contribution from our contributors past and present but special
mention for this release should be made to Daniel Sun for his
instrumental contributions to the Parrot parser and Eric Milles for
his recent improvements to Groovy's static compiler.

For more information on how to report problems, and to get involved,
visit the project website at 
https://groovy.apache.org/<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroovy.apache.org%2F&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C81951fcb609a43e9196708d7ae7335b2%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C637169682164371036&sdata=8UvCarDNzd6FhUNNNivcpmMZiZZSKbInsZHMbvd6Qa0%3D&reserved=0>

Best regards,

The Apache Groovy team.


Sensitivity: Internal


Sensitivity: Internal

RE: [ANNOUNCE] Apache Groovy 3.0.0 released

[Winnebeck, Jason]

Amazing news! Is there a page with a summary of changes from 2.x series along 
with any compatibility/migration notes? I see the changelog for 
3.0.0 but not sure if 
that is from RC3 or from something else.

Jason

From: Paolo Di Tommaso 
Sent: Monday, February 10, 2020 9:56 AM
To: users@groovy.apache.org
Subject: Re: [ANNOUNCE] Apache Groovy 3.0.0 released

Congrats, folks!! 👏👏👏

On Mon, Feb 10, 2020 at 3:46 PM Søren Berg Glasius 
mailto:soe...@glasius.dk>> wrote:
Awesome. A new Era has begun 😊
Med venlig hilsen / Best regards

Søren Berg Glasius

Sent from my phone, thus brief

On Mon, Feb 10, 2020, 14:06 Paul King 
mailto:pa...@apache.org>> wrote:
Dear community,

The Apache Groovy team is pleased to announce version 3.0.0 of Apache Groovy.
Apache Groovy is a multi-faceted programming language for the JVM.
Further details can be found at the 
https://groovy.apache.org
 website.

We are sure you'll enjoy the features in this new version of Groovy.
Your feedback on any unintentional glitches is welcome.

This release includes 15 bug fixes/improvements since RC3 as outlined
in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12345566
(There are over 500 new features, improvements and bug fixes since Groovy 2.5!)

Sources, convenience binaries, downloadable documentation and an SDK
bundle can be found at: 
https://groovy.apache.org/download.html
We recommend you verify your installation using the information on that page.

Jars are also available within the major binary repositories.

We welcome your help and feedback and in particular want to thank
everyone who contributed to this release. We value all forms of
contribution from our contributors past and present but special
mention for this release should be made to Daniel Sun for his
instrumental contributions to the Parrot parser and Eric Milles for
his recent improvements to Groovy's static compiler.

For more information on how to report problems, and to get involved,
visit the project website at 
https://groovy.apache.org/

Best regards,

The Apache Groovy team.


Sensitivity: Internal

RE: finding value of key at same level as another key

[Winnebeck, Jason]

def parsed = new JsonSlurper().parseText(json)
assert parsed.status.group == 'group1'
assert parsed.status.partitions.find { it.topic == 'topic1' && it.partition == 
0 }?.end?.lag == 0

Putting your JSON into a string variable “json”, the above asserts pass. The 
group was not put into a find because the status field is an object, not an 
array, so you’d check it with a normal if statement rather than find. The 
result is the end.lag field of the first partition found matching the topic and 
partition number, or null if no partition was found, or the first partition 
found does not have the field, or if the field exists but is null.

If you want to limit only to partitions with lag defined, you can change the 
search accordingly:

assert parsed.status.partitions.find { it.topic == 'topic1' && it.partition == 
0 && it.end?.lag != null }?.end?.lag == 0

Jason

From: Brandon Metcalf 
Sent: Tuesday, November 27, 2018 12:20 PM
To: users@groovy.apache.org
Subject: finding value of key at same level as another key

Hello,

I have the following json

{
  "status": {
"group": "group1",
"partitions": [
  {
"topic": "topic1",
"partition": 0,
"start": {
  "offset": 0,
  "timestamp": 1543337772415,
  "lag": 0,
  "max_offset": 0
},
"end": {
  "offset": 0,
  "timestamp": 1543337812000,
  "lag": 0,
  "max_offset": 0
}
  }
]
  }
}

I'm looking for a way in groovy to find the value of status.partitions.end.lag 
when I know the values of status.group, status.partitions.topic and 
status.partitions.partition?  I may need to rethink my approach to how I think 
I should parse this json, but hopefully there is an easy way to do this.

Also, there can be multiple levels of the values that I know.  Just showing one 
for simplicity.

Thanks.

groovyw

[Winnebeck, Jason]

Is there a javaw equivalent to groovy, such as groovyw? For example if I want a 
single file groovy script that launches a GUI and I don't want the console. I 
was very surprised there is not already a groovyw variant in groovy 2.5.3 
binary and I couldn't readily find a solution for this when searching. Groovyc 
+ javaw doesn't really work very well due to need to set up Groovy on classpath.

Jason Winnebeck
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

MethodClosure issues

[Winnebeck, Jason]

I have an odd issue with method closures. I'm on Groovy 2.4.12 in dynamic mode 
and I'm trying to transform data to a map for a webservice. I don't know if I'm 
using wrong syntax or if it's a Groovy bug.

This line of code results in MissingMethodException:
response.pa.opportunityQuotes   = 
pa.opportunityQuotes.collect(this.&mapOpportunityQuote)

pa.opportunityQuotes returns List and mapOpportunityQuote is an instance 
method taking a Quote and returning a Map. The method containing above line is 
in AbstractPAService but at runtime "this" is a Service class extends 
AbstractPAService. The MissingMethodException says there's no 
Service.mapOpportunityQuote method, which is technically true as the method is 
on AbstractPAService. Whether mapOpportunityQuote is protected or private does 
not matter.

This line of code does work, which makes me think I hit a Groovy bug and not 
something in my code:


response.pa.opportunityQuotes   = pa.opportunityQuotes.collect { 
((AbstractPAService) owner).mapOpportunityQuote(it) }

The usage of owner and downcasting it to AbstractPAService should be redundant.

I want the MethodClosure created by this.&mapOpportunityQuote to resolve the 
method on AbstractPAService class, not on Service class that extends it. 
Although, I'm confused why making mapOpportunityQuote protected did not 
workaround the issue.

Jason Winnebeck
Software Engineer III Contractor - IT Software Development | Windstream
600 Willowbrook Office Park, Rochester, NY 14450
jason.winneb...@windstream.com | 
windstreambusiness.com
o: 585.794-4585

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: GraalVM/Truffle ?

[Winnebeck, Jason]

It’s interesting that it is slower, because I thought the point of it was to 
improve performance, especially regarding escape analysis and invokedynamic 
instruction? They’ve been publishing some very interesting benchmarks. The AOT 
mode is very interesting, too, especially if someone wanted to make some CLI 
commands in Groovy, although the resulting executables are still very large if 
you just wanted to make some shell “scripts” in Groovy. Though, I would suspect 
its AOT mode is not very compatible with Groovy due to extensive use of 
reflection.

Jason

From: Paul King [mailto:pa...@asert.com.au]
Sent: Thursday, June 14, 2018 4:30 AM
To: users@groovy.apache.org
Subject: Re: GraalVM/Truffle ?

Running numerous scripts on GraalVM worked fine for me and was only slightly 
slower in my tests than the standard Oracle JVM. I haven't done extensive 
testing though.

As for actually leveraging any special GraalVM capabilities, I am not aware of 
any completed work/concrete plans to date.

As for licensing, it may or may not be an issue. We'll have to see how things 
progress before we can say.

Cheers, Paul.


On Thu, Jun 14, 2018 at 1:33 AM MG 
mailto:mg...@arscreat.com>> wrote:
Since GraalVM 
(https://en.wikipedia.org/wiki/GraalVM)
 was mentioned here
recently: Do we have any statement on plans of Groovy with regards to
GraalVM, including Truffle ? It might be good to have an official
statement here on the main Groovy page and on Wikipedia
(https://en.wikipedia.org/wiki/Apache_Groovy),
 even if it e.g., in
essence, just states "Groovy runs/will run fine on GraalVM", "The
Truffle license (GPL 2.0 w CP exception) is not compatible with Apache
Groovy" or "Truffle makes no sense for Groovy (at this point)"...

Cheers,
mg


This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: [ANNOUNCE] Apache Groovy 2.5.0-rc-3 released

[Winnebeck, Jason]

Thanks, I see the notes. Mostly looks like new features. Are there any benefits 
to upgrading if not taking advantage of the new features yet (that is, does it 
improve existing code)? I see some improvements for example around the Optional 
usage, although if we were using Optional now it appears it would be broken, so 
it’s more of a pre-emptive bug fix. It also seems to be beneficial to upgrade 
to prevent the possibility of inserting new changes that would break upon 
upgrade, such as relying (or not) on the linked list behavior changes.

Jason

From: Paul King [mailto:pa...@asert.com.au]
Sent: Tuesday, May 22, 2018 12:21 PM
To: users@groovy.apache.org
Subject: Re: [ANNOUNCE] Apache Groovy 2.5.0-rc-3 released

This is the place to look:

http://groovy-lang.org/releasenotes/groovy-2.5.html<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy-lang.org%2Freleasenotes%2Fgroovy-2.5.html&data=02%7C01%7CJason.Winnebeck%40windstream.com%7C8522cb5ec16d49cf147b08d5c00011e7%7C2567b4c1b0ed40f5aee358d7c5f3e2b2%7C1%7C0%7C63662602565866&sdata=31XsDo7PIzwze%2Bn4%2Fi5wgrcH7XcbL4yPHfDvAZLnrrI%3D&reserved=0>

We still need to do some updates between now and GA release.

Cheers, Paul.

On Wed, May 23, 2018 at 2:16 AM, Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>> wrote:
Is there a page summarizing the changes since 2.4, to evaluate if/where any 
issues are with backwards compatibility?

Jason Winnebeck

-Original Message-
From: Paul King [mailto:pa...@apache.org<mailto:pa...@apache.org>]
Sent: Tuesday, May 22, 2018 12:03 PM
To: d...@groovy.apache.org<mailto:d...@groovy.apache.org>; 
users@groovy.apache.org<mailto:users@groovy.apache.org>; 
annou...@apache.org<mailto:annou...@apache.org>
Subject: [ANNOUNCE] Apache Groovy 2.5.0-rc-3 released

Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-rc-3 of Apache 
Groovy.


This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: [ANNOUNCE] Apache Groovy 2.5.0-rc-3 released

[Winnebeck, Jason]

Is there a page summarizing the changes since 2.4, to evaluate if/where any 
issues are with backwards compatibility?

Jason Winnebeck

-Original Message-
From: Paul King [mailto:pa...@apache.org] 
Sent: Tuesday, May 22, 2018 12:03 PM
To: d...@groovy.apache.org; users@groovy.apache.org; annou...@apache.org
Subject: [ANNOUNCE] Apache Groovy 2.5.0-rc-3 released

Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-rc-3 of Apache 
Groovy.


This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy 3 lambda, method reference, default methods

[Winnebeck, Jason]

That's cool that it's basically a separate project. I wonder if IntelliJ itself 
can use the Parrot parser then to parse Groovy code, in that case it would 
always be guaranteed to be 100% "compatible", at least from a syntax 
perspective. I bet same concept could apply to code analysis tools.

Jason

-Original Message-
From: Daniel.Sun [mailto:sun...@apache.org] 
Sent: Wednesday, March 21, 2018 12:11 PM
To: us...@groovy.incubator.apache.org
Subject: RE: Groovy 3 lambda, method reference, default methods

You can write Java8 style code(e.g. lambda, method/constructor reference,
etc.) when Parrot parser is enabled :-)
See https://github.com/danielsun1106/groovy-parser


> Is there then a major difference in language between 2.6+Parrot and 3.0?

3.0 enables Parrot parser by default, so no differences.


> I wonder if the IntelliJ support ticket should be updated to say 
> support new language features in Groovy 2.6 as well?

I see the title contains "Groovy 3", so I am not sure if it will support 2.6


Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy 3 lambda, method reference, default methods

[Winnebeck, Jason]

This is major news, if the performance is comparable to Java. So with 
2.6.0-alpha-3, Parrot, and JDK8+ you can use lambda expressions in static 
groovy and have them compiled to native lambda, or is it using closure syntax?

Is there then a major difference in language between 2.6+Parrot and 3.0?

I wonder if the IntelliJ support ticket should be updated to say support new 
language features in Groovy 2.6 as well?

Jason

-Original Message-
From: Daniel.Sun [mailto:sun...@apache.org] 
Sent: Wednesday, March 21, 2018 11:50 AM
To: us...@groovy.incubator.apache.org
Subject: Re: Groovy 3 lambda, method reference, default methods

Up to now native lambda is available under compile static mode in 
3.0.0-alpha-2(will be released soon) and 2.6.0-alpha-3(Parrot parser is 
required enabled and using Java8+).

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Groovy 3 lambda, method reference, default methods

[Winnebeck, Jason]

I took a look at the new Groovy 3 changes at 
http://groovy-lang.org/releasenotes/groovy-3.0.html and noticed there is still 
a question as to whether or not to implement lambdas, method references, and 
default methods as closures and traits. Is the Groovy team still taking 
feedback on these decisions?

If so, my vote would be to by default, emit JDK8+ "native" implementations 
wherever possible. I would even go as far to say to allow Groovy 3 to emit 
JDK8+ lambdas for any expression where a closure inline to a method taking a 
SAM, as a way to improve Groovy 2 code, but I can understand why it might be 
better to be consistent and have closure blocks always generate closures (as 
closures have delegate concept that extends Java lambdas).

The reason for my vote is I work on a large Groovy project where performance is 
a significant consideration. My experience so far is that using closures with 
streams has poor performance such that any time I want to use streams I either 
write the class in Java or I make a utility class with the Streams code and 
call that utility class from Groovy. It is unfortunate that JDK 8's 
enhancements make Groovy feel a lot less necessary to me, especially since I 
learned how hard it is to avoid BigDecimal math even when using CompileStatic. 
We are working with a business rules system and sometimes a single rule can 
trigger 1k+ times within a single page refresh, so we have to pay attention to 
which Groovy features we use in certain rules. Avoiding closures, using for in 
preference to .each, etc., can result in order of magnitude speedup. That's why 
my vote is to have Groovy compile static generate code as close to Java as 
possible, whenever a choice is possible.

Jason Winnebeck

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

float math in Groovy and IntelliJ

[Winnebeck, Jason]

I noticed in latest IntelliJ IDEA 2017.3.3 it has started to flag the following 
code as an red error, as if it was a compile error:

float a = 1
float b = 2

float c = a + b

It says loss of precision when assigning to c. It is true per 
http://docs.groovy-lang.org/latest/html/documentation/core-syntax.html#_math_operations
 that a float + float is a double, for whatever (probably historical) reason. 
But this is not supposed to be a compiler error in compile static mode? It 
seems as worst case this should be a warning. But even if it's a warning, is 
this inappropriate Groovy code? Should c always be of type double? Should float 
be avoided? Would a cast always be appropriate style?

Jason Winnebeck
Software Engineer III Contractor - IT Software Development | Windstream
600 Willowbrook Office Park, Rochester, NY 14450
jason.winneb...@windstream.com | windstreambusiness.com
o: 585.794-4585

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: @CompileStatic null iteration

[Winnebeck, Jason]

It’s been like this for as long as I’ve been using compile static in Groovy. I 
assumed that was expected behavior and I make sure to point it out to all new 
developers in our project as one of the Groovy gotchas. Is it not supposed to 
be that way?

Jason

From: Paolo Di Tommaso [mailto:paolo.ditomm...@gmail.com]
Sent: Friday, December 15, 2017 2:29 AM
To: users@groovy.apache.org
Subject: Re: @CompileStatic null iteration

Just found the same problem. This difference can introduce subtle bugs when 
refactoring groovy code to CompileStatic.

I suggest to report a bug for that.


Cheers, Paolo


On Tue, Dec 12, 2017 at 12:45 AM, MG 
mailto:mg...@arscreat.com>> wrote:
Hi guys,

just a quick question since we came across it today when testing code that had 
been converted from dynamic to static Groovy: Is the behavior that statically 
compiled Groovy throws a NPE when the iterable to be iterated over is null 
(same as Java), while dynamically compiled Groovy uses the 
NullObject.iterator(), i.e. does not throw but instead iterates over an empty 
collection by design ?

Cheers,
mg



This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Consider statically typed/compiled as default for Groovy 3.0

[Winnebeck, Jason]

As for #2, note that Groovy code is compiled to bytecode as any other Java 
class. I use DCEVM + IntelliJ IDEA’s groovy gragent for hotswapping Groovy code 
and it works reasonably well. Not as good as Java, but Groovy works pretty 
well. It works well if you make sure not to add or remove closures when 
hotswapping. The vast majority of our code is static compiled. For reasons of 
performance, hotswapping, and debugging capability we use static as much as 
possible and try to reduce closures in use, even though they are the most 
powerful feature, we don’t use closures for example like with “each” method, 
instead we use plain for loops. Unfortunately, for some newer code now that we 
are on Java 8 where we used to have heavy closures code we instead use a Java 
helper class so we can use Streams API, which does not work well in Groovy, and 
also has the performance and hotswapping benefits.

If I was to consider forcing all Groovy code to static compilation at this 
time, I would seriously consider Kotlin instead of Groovy. Kotlin did not exist 
when we started our projects. That said, I have found no other JVM solution for 
dynamic consumption and production of webservices and schema-less structured 
data that compares to Groovy, and a hybrid Java+Kotlin+dynamic Groovy project 
is at best overcomplicated and I’m not even sure circular dependency is 
possible between the languages, therefore Groovy is still our language of 
choice for pairing with Java.

#4 is already implemented. In JVM the common language is bytecode and Groovy is 
a syntax sugar over bytecode, and bytecode already has a mapping of 
instructions to source code which is understood already by all JVM debugging 
tools. To do literally what you suggest would involve discarding the vast 
majority of the Groovy compiler and rewriting it to output Java code, which 
might not look much better than fernflower’s output but with improved variable 
names and possibly transfer of Javadoc. The other issue is that Groovy is a lot 
more than Java++ and requires a lot of helper code, particularly the MOP with 
dynamic groovy, that the Java output would not look like any kind of idiomatic 
Java that developers would want to work with.

Jason


From: Paco Zarate [mailto:conta...@nazcasistemas.com]
Sent: Monday, October 16, 2017 2:36 PM
To: users@groovy.apache.org
Cc: Paul King 
Subject: Re: Consider statically typed/compiled as default for Groovy 3.0

I really like this topic.
1) Groovy syntax is incredible readable/maintainable. I take Groovy code from 
years ago and I am able to make changes easily. Thank you guys for this!

2) The dynamic portion of Groovy is interesting but it has some limits: when 
you are coding you need to recompile to see a change on a single line. Is it 
possible to have a the code recompiled on the fly? Is it possible in Groovy to 
step back during the debug? And finally, would be a way to be debugging Groovy 
code, hit a breakpoint, modify some already executed code on the fly, step back 
and rerun it? I guess all this is more tooling related than language related, 
but I would appreciate your opinions.

3) Have you seen the Smalltalk;s Pharo environment? they have visual tools to 
access and modify the Smalltalk app internals.  For example, see all the 
objects and modify then in the fly, include more code, save the state of the 
app (image) and reload it later. It is really interesting and I wonder if 
Groovy could use its dynamic nature that way.

4) For the static portion of Groovy: Have you think in the Typescript way of 
doing things? They are the "javascript++" but they have been doing it though 
transpiling to a very readable javascript. The option I see, would be to have 
Groovy generating Java code + maps for debugging. The use case would be: you 
work in a Java company, use Groovy to develop and then deliver to your company 
very readable Java code. I guess this may be doable with CompileStatic Groovy 
code and have a chance to apply too to generate Android Java code.


On Fri, Oct 13, 2017 at 7:14 AM, Cédric Champeau 
mailto:cedric.champ...@gmail.com>> wrote:
Wise words, Paul. I would also very much prefer to see progress in the Java 9 
area rather than this, or even the parser. It's much more relevant to the 
future of Groovy IMHO. Because, as the ticket explains, there's already ways to 
enable this feature (even if a bit cumbersome). It's really of that importance, 
then a pull request, accepted through a VOTE, would certainly be the fastest 
way to get this.

2017-10-13 15:11 GMT+02:00 Paul King 
mailto:pa...@asert.com.au>>:
I think most committers are also keen on making progress in the directions you 
describe. Not along the lines of watering down Groovy's dynamic capabilities 
but certainly in terms of making Groovy's static nature as hassle free as 
possible to use. Having said that, we have limited resources, so we need to 
prioritise and do a limited numbers of things well rather than half do lots of 
thi

RE: Groovy 2.5.0-beta-1 released

[Winnebeck, Jason]

I see there is Elvis support for Optional, which is pretty cool.

But when there are breaking changes like this that affect runtime behavior 
without a change in code, is there a place where this is documented when the 
release comes out? It would be a nice section to include for Groovy 2.5 
documentation a list of breaking changes so you can find any issues in code.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Tuesday, June 06, 2017 7:45 AM
To: d...@groovy.apache.org; users@groovy.apache.org
Subject: Groovy 2.5.0-beta-1 released

Dear community,

The Apache Groovy team is pleased to announce version 2.5.0-beta-1 of Apache 
Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This is a pre-release of a new version of Groovy.
We greatly appreciate any feedback you can give us when using this version.

This release includes 8 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12331949

Sources can be downloaded from: http://www.groovy-lang.org/download.html
Convenience binaries, SDK and documentation can be found at: 
http://www.groovy-lang.org/download.html
Jars are also available within the major binary repositories.
We would like to thank all people who contributed to this release.

We welcome your help and feedback. For more information on how to report 
problems, and to get involved, visit the project website at 
https://groovy.apache.org/

Best regards,

The Apache Groovy team.

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Binary to Base64 Conversion

[Winnebeck, Jason]

You can use built-in encodeBase64 method in Groovy:

assert "AQID" == ([1,2,3] as byte[]).encodeBase64() as String

And you saw, decodeBase64 is the opposite. Does that do what you want?

Jason

From: Nelson, Erick [mailto:erick.nel...@hdsupply.com]
Sent: Friday, May 12, 2017 10:07 PM
To: users@groovy.apache.org
Subject: Re: Binary to Base64 Conversion

Apache Commons codec

https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/binary/Base64.html

Erick Nelson
Senior Developer
HD Supply, FM
Cell 858-740-6523
Home 760-930-0461

CONFIDENTIALITY NOTICE: This message is for intended addressee(s) only and may 
contain information that is confidential, proprietary or exempt from 
disclosure, and subject to terms at: http://www.hdsupply.com/email.

From: RJ mailto:ssogu...@gmail.com>>
Reply-To: "users@groovy.apache.org" 
mailto:users@groovy.apache.org>>
Date: Friday, May 12, 2017 at 7:05 PM
To: "users@groovy.apache.org" 
mailto:users@groovy.apache.org>>
Subject: Binary to Base64 Conversion

I have to deal with a binary value of base64 ID in a groovy script. So, first I 
need to covert binary data to base64 format and then decodeBase64().
Any clues/thoughts ? Thanks!!

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy AOT compilation

[Winnebeck, Jason]

I think a biggest question than AOT compatibility is why does compile static 
still need to do reflection? I thought that was the point was to disable it, 
especially for Android support…? Unless the issue is the metaclass generation, 
does compile static still generate metaclasses?

Jason

From: Paolo Di Tommaso [mailto:paolo.ditomm...@gmail.com]
Sent: Monday, May 08, 2017 11:02 AM
To: users@groovy.apache.org
Subject: Groovy AOT compilation

Dear all,

I just want to share with you my experience with the Java AOT 
compiler
 a came across a few days ago.


Although they said clearly that it still an experimental project and it does 
not support dynamic class loading and most of reflection, I turns out it's 
possible to compile a basic static Groovy class, eg:

@groovy.transform.CompileStatic
class Hello {

  static void main( String... args ) {
System.out.println "Hello world!"
  }
}


This mean that it creates a native 5MB binary executable, that can run on any 
machine without the need of the Java VM nor the Groovy runtime! in 12 
millisecond! cool!!


Unfortunately the good news stops here. I was unable to successfully compile 
any other piece of code, which for example uses a Groovy "println" method or 
just instantiate a class. The problem seems to be that, even though the code is 
statically compiled, Groovy uses reflection behind the scene to instantiate 
classes and performs other operations.

Now, I guess this is certainly not a Groovy top priority, however since there 
is an on-going discussion around a major Groovy reengineering to make it 
compatible with the upcoming Java 9 module system, I was wondering if it would 
not make sense to include the support for the Java AOT compiler as a goal for a 
future Groovy 3/4 release?

Personally I think it would be an extremely useful feature and a major 
achievement for the project.


What do you think ?


Cheers,
Paolo



This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: How to determine the equality of two closures?

[Winnebeck, Jason]

That's cool, so that defines lastValue as a field of the actual closure class?

The issue with using a field is the watch not using the map would fail when 
performing multiple watches:

person.watch({skills}
person.watch({name}...

In those two values, the lastValue field would confuse the state between the 
{skills} watch and the {name} watch. Also I didn't want to complicate the 
example but in the real implementation the watch is a utility class shared 
between many objects and classes and not a closure so my watch state map key is 
the watched instance + watch closure class and the map is the field of a real 
class. In real a scripting DSL example I would have probably added watch to 
Object metaclass which delegates to a WatchManager implementation.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Thursday, April 13, 2017 11:39 AM
To: users@groovy.apache.org
Subject: Re: How to determine the equality of two closures?

Jason, have you ever trief something like this?

>  person.watch = { cond, action, elseAction ->
>def value = person.with(cond).clone()
>@groovy.transform.Field lastValue
>if (value != lastValue) action(lastValue, value) else elseAction()
>lastValue = value
>  }

bye Jochen

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: How to determine the equality of two closures?

[Winnebeck, Jason]

I wrote my reply before I saw your use case of Gradle build scripts. My 
technique probably won’t work there because I assume the build script is 
re-compiled between each run so would give a different class object, but I 
don’t know how the up-to-date check works…

Here is what I did. In this example each time runScript runs and calls watch, 
despite the “cond” closure being different instances each time, they are all of 
the same class so that’s how I know it’s the same call site. However, if I made 
another function “runScript2” even if it had identical code, the closures would 
not compare “equal” for my use case (which in my watch case, is exactly what 
I’d want anyway).

def person = [name: 'Jason', skills: ['Groovy']]

def watches = [:]

person.watch = { cond, action, elseAction ->
def value = person.with(cond).clone()
def lastValue = watches[cond.class]
if (value != lastValue) action(lastValue, value) else elseAction()
watches[cond.class] = value
}

void runScript(def p) {
p.watch({skills},
 {o, n -> println "Skills are now $n"},
 {println "Skills have not changed"})
}

runScript(person)
runScript(person)
person.skills << 'Java'
runScript(person)

Output:
Skills are now [Groovy]
Skills have not changed
Skills are now [Groovy, Java]

From: bo zhang [mailto:zhangbo...@gmail.com]
Sent: Thursday, April 13, 2017 11:05 AM
To: users@groovy.apache.org
Subject: Re: How to determine the equality of two closures?

Sorry Jason, but I don't quite understand, would you please explain it more 
detailedly? Thanks a lot.

2017-04-13 22:28 GMT+08:00 Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>>:
Jochen, I had a use case that was very close to this that may or may not 
inspire bo zhang for an alternative solution to closure equality. I had to rely 
on the Groovy implementation detail that each Closure instance created from an 
expression at a line of code had the same class (I did put this assumption in a 
unit test in my project so I'd know if that broke). That let me create a DSL 
like AngularJS watches:

def person = [name: 'Jason', skills: ['groovy']]

person.watch( {skills} ) {oldVal, newVal ->
  println "person.$name's skills changed from $oldVal to $newVal"
}

To implement the watch method, I have a map of Class to watcher's state. So 
when the person.watch expression is run again, the state is preserved from the 
last run, using the closure's class as the key to recover the state. In this 
example, two watches with the same closure definition would have two states. 
But if I put the two watch into a function, the closures would share the same 
line of code and compare as "equal"

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org<mailto:blackd...@gmx.org>]
Sent: Thursday, April 13, 2017 10:08 AM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Re: How to determine the equality of two closures?



On 13.04.2017 15:56, bo zhang wrote:
> Hello everybody,
>
> I just have encountered a problem thus need your help. I want to treat
> the following closures as "equivalent":
>
> Clousure c1={
> "This is a closure"
> }
>
> Clousure c2={
> "This is a closure"
> }
>
> assert closureEqual(c1,c2)

may I ask how you want to use that? I was thinking about this in the past, but 
I failed to create a reasonable scenario in which I would need this.

> Apparently, even though all fields and methods (the internal bytecode)
> are equal, c1 and c2 are still different classes (xxx_closure$1 and
> xxx_closure$2). AFAIK, everything but name in these two classes are equal.
>
> Is there any possibilities to achieve my goal? Thank you very much.

right now, not no.

bye Jochen
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: How to determine the equality of two closures?

[Winnebeck, Jason]

Jochen, I had a use case that was very close to this that may or may not 
inspire bo zhang for an alternative solution to closure equality. I had to rely 
on the Groovy implementation detail that each Closure instance created from an 
expression at a line of code had the same class (I did put this assumption in a 
unit test in my project so I'd know if that broke). That let me create a DSL 
like AngularJS watches:

def person = [name: 'Jason', skills: ['groovy']]

person.watch( {skills} ) {oldVal, newVal ->
  println "person.$name's skills changed from $oldVal to $newVal"
}

To implement the watch method, I have a map of Class to watcher's state. So 
when the person.watch expression is run again, the state is preserved from the 
last run, using the closure's class as the key to recover the state. In this 
example, two watches with the same closure definition would have two states. 
But if I put the two watch into a function, the closures would share the same 
line of code and compare as "equal"

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Thursday, April 13, 2017 10:08 AM
To: users@groovy.apache.org
Subject: Re: How to determine the equality of two closures?



On 13.04.2017 15:56, bo zhang wrote:
> Hello everybody,
>
> I just have encountered a problem thus need your help. I want to treat 
> the following closures as "equivalent":
>
> Clousure c1={
> "This is a closure"
> }
>
> Clousure c2={
> "This is a closure"
> }
>
> assert closureEqual(c1,c2)

may I ask how you want to use that? I was thinking about this in the past, but 
I failed to create a reasonable scenario in which I would need this.

> Apparently, even though all fields and methods (the internal bytecode) 
> are equal, c1 and c2 are still different classes (xxx_closure$1 and 
> xxx_closure$2). AFAIK, everything but name in these two classes are equal.
>
> Is there any possibilities to achieve my goal? Thank you very much.

right now, not no.

bye Jochen

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Maven coordinates going forward

[Winnebeck, Jason]

I think others have characterized it differently, but in my mind that is the 
“Python” scenario. Groovy 3 comes out and immediately makes all existing code 
incompatible. Without an incremental upgrade path, users, especially enterprise 
users, are faced with a rewrite and have no choice but to basically stay on 
Groovy 2 forever. With so many users staying on 2.x, it will fragment the 
community and the limited support that Groovy receives. While http-builder-ng 
is a good example of an updated project, even for that project’s documentation 
says it’s not backwards compatible so it’s not a drop-in replacement either. At 
least with Java library usage being very popular, there will be a lot of 
libraries we can still use in G3. If it’s still possible for G2 to co-exist, 
then at least I can update my own code to G3 while I wait (perhaps forever) for 
libraries to update to G2, and I can deploy upgrades incrementally. An atomic 
rewrite all functionality from scratch is never a valid scenario for 10+ year 
old projects.

Jason

From: Guillaume Laforge [mailto:glafo...@gmail.com]
Sent: Thursday, March 30, 2017 10:21 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

And there's also groovy-wslite.

Also we can't wait for all possible abandonned project to update to a newer 
version of Groovy.
Those projects depending on libraries using an old version of Groovy should 
probably just not upgrade at all.

On Thu, Mar 30, 2017 at 4:09 PM, David Clark 
mailto:plotinussm...@gmail.com>> wrote:
The original http-builder is unmaintained. However http-builder-ng is 
maintained:

https://http-builder-ng.github.io/http-builder-ng/

We already had to change the maven coordinates because of Maven/Sonatype 
restrictions, so things should be fine provided people upgrade to the newer 
library.

On Thu, Mar 30, 2017 at 8:12 AM, Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>> wrote:
Can you explain the story around a library like 
org.codehaus.groovy.modules.ht<http://org.codehaus.groovy.modules.ht>tp-builder:http-builder,
 which is no longer really maintained? What happens to such a library when 
Groovy 3 comes out and we are using that library? Let's say there is no 
maintainer to update the sources to Groovy 3 and re-release.

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk<mailto:rus...@winder.org.uk>]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.

So why not make Groovy 3 the place to do this?

Whatever has been said about the Python situation, the core problem was not the 
breaking change, the problem was the lack of active management of the change.

Python is a source deployment language where JRE-based langauges are not. Thus 
JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of 
"we've lost the source" (banks and governments are the usual suspects for 
this). I would exclude this situation from our thinking. Organisations in such 
a state (as some UK banks and the UK government is) should take it as an 
opportunity to revolutionise (which the UK government is, cf. the job adverts 
for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, 
etc.

Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix 
made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a 
much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then 
came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to 
create 2.7 and 3.4+ compatible code). The moral here is choose the versions 
being upgraded from and to, and then make some nice automation.

So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the 
breaking change of 3.0 can we write some Groovy (obviously :-) scripts that 
automate source changes?

If the Python 2 → Python 3 breaking change had been more actively managed with 
earlier arrival of six and future, the problems would have been much less. Most 
of the vocal Python 2 Remainers have now made their codes run on both Python 2 
and Python 3, and there are very few complaints about providing Python 3 only. 
OK so there are still a few people who say "we must support Python 2.5" but 
those people are few and far between and are, in the main, totally ignored.

RE: Maven coordinates going forward

[Winnebeck, Jason]

OK, in my mind that is perfectly fine. In this case the change of package name 
and Maven coordinates is required, but in this case it is a good thing. It’s a 
good thing because you are saying explicitly that both Groovy versions can 
co-exist, which is what separate packages and separate Maven coordinates allow 
you to do. As an example of how this was done very well I think of Jackson 1.x 
to 2.x where they can co-exist and use different packages/Maven coordinates. 
And also in my mind, it’s acceptable as an upgrade scenario because I can use 
legacy libraries not upgraded to Groovy 3 by treating them as I would any other 
JVM class, with just the decision of having extra overhead by having both 
Groovy 2 and Groovy 3 in my classpath.

I suppose there would need to be some compatibility layer though because of 
things like Closure being an abstract class, presumably Groovy 3 would have its 
own Closure type so there would need to be a converter/wrapper to pass a G3 
closure into a G2 class taking groovy.lang.Closure, unless groovy.lang.Closure 
is not going to change for G3. It sounds like worst-case these problems are 
solvable via a special Groovy 2-compat library that maybe excludes 
groovy.lang.Closure so that it defers to the G3 implementation.

Jason

From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Thursday, March 30, 2017 9:18 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

And again, _we have no choice_. If we want Groovy to run as a module, we HAVE 
to break binary compatibility. There's absolutely no other way around. It's a 
thing. If we don't want to break it, Groovy will never run as a module. And if 
JDK 9 modules become legion, then Groovy would die.

2017-03-30 15:16 GMT+02:00 Cédric Champeau 
mailto:cedric.champ...@gmail.com>>:
To me the idea would be to be able to run Groovy 2 and Groovy NG concurrently.

2017-03-30 15:12 GMT+02:00 Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>>:
Can you explain the story around a library like 
org.codehaus.groovy.modules.ht<http://org.codehaus.groovy.modules.ht>tp-builder:http-builder,
 which is no longer really maintained? What happens to such a library when 
Groovy 3 comes out and we are using that library? Let's say there is no 
maintainer to update the sources to Groovy 3 and re-release.

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk<mailto:rus...@winder.org.uk>]
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.

So why not make Groovy 3 the place to do this?

Whatever has been said about the Python situation, the core problem was not the 
breaking change, the problem was the lack of active management of the change.

Python is a source deployment language where JRE-based langauges are not. Thus 
JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of 
"we've lost the source" (banks and governments are the usual suspects for 
this). I would exclude this situation from our thinking. Organisations in such 
a state (as some UK banks and the UK government is) should take it as an 
opportunity to revolutionise (which the UK government is, cf. the job adverts 
for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, 
etc.

Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix 
made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a 
much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then 
came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to 
create 2.7 and 3.4+ compatible code). The moral here is choose the versions 
being upgraded from and to, and then make some nice automation.

So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the 
breaking change of 3.0 can we write some Groovy (obviously :-) scripts that 
automate source changes?

If the Python 2 → Python 3 breaking change had been more actively managed with 
earlier arrival of six and future, the problems would have been much less. Most 
of the vocal Python 2 Remainers have now made their codes run on both Python 2 
and Python 3, and there are very few complaints about providing Python 3 only. 
OK so there are still a few people who say "we must support Python 2.5" but 
those peop

RE: Maven coordinates going forward

[Winnebeck, Jason]

Can you explain the story around a library like 
org.codehaus.groovy.modules.http-builder:http-builder, which is no longer 
really maintained? What happens to such a library when Groovy 3 comes out and 
we are using that library? Let's say there is no maintainer to update the 
sources to Groovy 3 and re-release.

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk] 
Sent: Thursday, March 30, 2017 3:54 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is 
> supporting Groovy as a module. And this *will* require package changes 
> and binary breaking changes. So I don't think the status quo is 
> acceptable in the long run.

So why not make Groovy 3 the place to do this?

Whatever has been said about the Python situation, the core problem was not the 
breaking change, the problem was the lack of active management of the change.

Python is a source deployment language where JRE-based langauges are not. Thus 
JRE-based application have the classic COBOL, FORTRAN, and Fortran problem of 
"we've lost the source" (banks and governments are the usual suspects for 
this). I would exclude this situation from our thinking. Organisations in such 
a state (as some UK banks and the UK government is) should take it as an 
opportunity to revolutionise (which the UK government is, cf. the job adverts 
for COBOL, FORTRAN and Fortran knowledgeable people who also know Python, Java, 
etc.

Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix 
made for a very hard time. Allowing only 2.7 and 3.4+ in the mix made for a 
much, much easier time. So initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then 
came the six generation of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to 
create 2.7 and 3.4+ compatible code). The moral here is choose the versions 
being upgraded from and to, and then make some nice automation.

So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the 
breaking change of 3.0 can we write some Groovy (obviously :-) scripts that 
automate source changes?

If the Python 2 → Python 3 breaking change had been more actively managed with 
earlier arrival of six and future, the problems would have been much less. Most 
of the vocal Python 2 Remainers have now made their codes run on both Python 2 
and Python 3, and there are very few complaints about providing Python 3 only. 
OK so there are still a few people who say "we must support Python 2.5" but 
those people are few and far between and are, in the main, totally ignored. 
Python 4 will undoubtedly have breaking changes, but they will be better 
managed in terms of supporting multi-version working and automated (well at 
least
semi-automated) upgrading and mixed-version working. The lessons of six and 
future have been well learned.

So Groovy will have breaking changes, this is right and proper. Put in place 
tools for upgrading, and support multi-version working where possible and 
practical. Do not be swayed by calls for "we must change nothing, backward 
compatibility". They have a version of Groovy that works for them so they 
should not upgrade – ever again. That must not stop the rest of us from 
progressing.

--
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Maven coordinates going forward

[Winnebeck, Jason]

I don't know if it was totally clear from my previous mails, but I agree on not 
changing the package names, unless breaking changes are required and the 
package names need to change to preserve the ability of Groovy 1.x/2.x code to 
co-exist, avoiding the "Python 3 Effect". If the only breaking change would be 
the package change, then there's no sense to change the name just to change the 
name.

I think it is OK to change the Maven coordinates in any case. While it is used 
sometimes as a starting point to look at a class and try to figure out what 
library it comes from based on matching the package name to the group ID, 
that's not a common operation and modern IDEs (and search.maven.org) can easily 
answer the question if needed. The only drawback to changing Maven coordinates 
is it might make it harder for people to know there is a newer package, that 
is, to search for upgrades we check for more recent versions of current 
dependencies. However, with a project as big as Groovy I think it will be clear 
when Groovy 3 comes out that users will know.

Jason

From: Keith Suderman [mailto:suder...@anc.org]
Sent: Monday, March 27, 2017 2:49 PM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

+1 for changing Maven coordinates.

-1 for changing package names.  Sure, new code can use the new package names, 
but changing existing packages is just breaking changes for the sake of 
breaking things with no real benefit.  I hope the Groovy team tries to break as 
little as possible to avoid the "Python3 Effect", whether real or imagined.

Having said that, how much public facing code is in org.codehaus.groovy 
packages?  I don't think I've typed "import org.codehaus.groovy..." in my life, 
but IntelliJ may have inserted a few for me.

Keith


On Mar 27, 2017, at 2:20 PM, Jochen Theodorou 
mailto:blackd...@gmx.org>> wrote:

On 27.03.2017 20:08, Winnebeck, Jason wrote:

The key thing in my mind is that you can't make a change that breaks
100% of libraries at one time without fracturing the community or at
least introducing a major hindrance to upgrade that will mean
maintaining 2.x series for a very long time. Even if the upgrade
process is as easy as a recompile, there are a lot of published
libraries no longer maintained. Even for the ones that are
maintained, there are people who might not want to be forced to
upgrade every library. I'm not a Grails user, but my impression is
that the framework relies on a lot of plugins and is one of the (if
not the most) active Groovy communities and I have a hard time
envisioning how that upgrade path will take. You'd have to maintain
Groovy 2 and Groovy 3 versions of each plugin, and to upgrade you'd
have to upgrade everything at one time to the (most likely) latest
version.

What is the possibility that the package names are changed, the
parser, metaprogramming model, etc. that all break in Groovy 3
change, but yet still have a compatibility JAR implementing the
minimal Groovy 2.x classes in a way that allows interoperability with
Groovy 3 code? Theoretically at a worst case, Groovy 3 should be able
to view Groovy 2 classes the same way as any other Java class. I
think many concerns would be lifted if Groovy 2 and 3 could co-exist
at the same time, allowing you to upgrade incrementally.

If you see the new metaprogramming model as chance, then it would make sense to 
implement that in the new packages instead of transferring old and to be 
deprecated classes. The goal would the to be able to run old and new system at 
the same time, where the Groovy 1.x/2.x classes would use Groovy 3.x/4.x 
classes as implementation.

The problem with this approach is simply manpower and of course some conceptual 
problems still to be solved.

bye Jochen

--
Keith Suderman
Research Associate
Department of Computer Science
Vassar College, Poughkeepsie NY
suder...@cs.vassar.edu<mailto:suder...@cs.vassar.edu>




This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Maven coordinates going forward

[Winnebeck, Jason]

The key thing in my mind is that you can't make a change that breaks 100% of 
libraries at one time without fracturing the community or at least introducing 
a major hindrance to upgrade that will mean maintaining 2.x series for a very 
long time. Even if the upgrade process is as easy as a recompile, there are a 
lot of published libraries no longer maintained. Even for the ones that are 
maintained, there are people who might not want to be forced to upgrade every 
library. I'm not a Grails user, but my impression is that the framework relies 
on a lot of plugins and is one of the (if not the most) active Groovy 
communities and I have a hard time envisioning how that upgrade path will take. 
You'd have to maintain Groovy 2 and Groovy 3 versions of each plugin, and to 
upgrade you'd have to upgrade everything at one time to the (most likely) 
latest version.

What is the possibility that the package names are changed, the parser, 
metaprogramming model, etc. that all break in Groovy 3 change, but yet still 
have a compatibility JAR implementing the minimal Groovy 2.x classes in a way 
that allows interoperability with Groovy 3 code? Theoretically at a worst case, 
Groovy 3 should be able to view Groovy 2 classes the same way as any other Java 
class. I think many concerns would be lifted if Groovy 2 and 3 could co-exist 
at the same time, allowing you to upgrade incrementally.

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk] 
Sent: Monday, March 27, 2017 1:29 PM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

On Mon, 2017-03-27 at 12:47 -0400, Gerald Wiltse wrote:
> 
[…]
> Specifically, reaching out to the Python maintainers for guidance.  In 
> hindsight, someone deeply involved usually has a very clear vision of 
> "What we should have done instead was...".  It would be a major missed 
> opportunity if nobody pursues that avenue.
> 
[…]

I cannot speak for the core developers, but I am sure I could ask them via the 
various Python mailing lists. The introduction of Python 3 was not handled well 
in my view from the social and management perspective and this led to a 
majority of the tribalism issues that were seen. The changes to the data model 
were large, and needed, and affected library writers more than end users. The 
biggest change that affected end users was the shift from ASCII to Unicode as 
the representation of strings.
This broke any code using strings for networking.

Not having packages such as future and six, and tools such as 2to3 properly in 
place before the mass push to Python 3 was a bit of a problem.

However the single biggest problem was that many influential people said 
"Python 3, no way" from the outset. Also a couple of high profile projects said 
"the issue of strings is too big, we will not change". A well-thought of Python 
distribution refused to accept the existence of Python 3, and out of that that 
distribution is now dead and Anaconda/Miniconda from Continuum Analytics is now 
the default distribution for people not use an OS with packaging – or actually 
sometimes anyway. Also a few Linux distributions based on mass use of Python 
are based on code that is at least a decade old (Scientific Linux, I am looking 
at you).

All of this led to a Python 2 vs Python 3 warfare that was almost totally 
nothing to do with technicalities. It was to do with vested interests and 
financial muscle. It became tribal almost like the Green/Purple Drazi in 
"Geometry of Shadows" an episode of Babylon 5 htt 
ps://www.youtube.com/watch?v=AcBTOU7RvbU .

It has taken a long time for Python 3 to become ascendant but ascendant it is. 
The old "stick with Python 2" project have quietly enabled Python 3 and tried 
to avoid any publicity about this.

So the change was a technical success and a management and social failure.

Thus changing the package names is a management problem not a technical 
problem. So the only real question is how to enable redirection at dynamic link 
time.
 
--
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Maven coordinates going forward

[Winnebeck, Jason]

So that means we'll have a Python 3 situation where no code compiled with 
Groovy 2.x will ever be used again, unless the authors all release Groovy 
3-specific versions?

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk] 
Sent: Monday, March 27, 2017 11:40 AM
To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward

On Mon, 2017-03-27 at 09:58 -0500, David Clark wrote:
> Will this also change the package names to org.apache.groovy or will 
> those remain org.codehaus.groovy?
> 

The two are independent. I suggest changing both at the same time would
be the right thing to do.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Testing the Java 8 / Parrot parser online!

[Winnebeck, Jason]

That is awesome. If the Java 8 syntax is supported, does that mean Groovy will 
support lambdas? One thing that saddened me about using Java 8 from Groovy is 
that you have the overhead of closure classes/meta class and the “dynamic” 
conversion/proxy into the Java functional interfaces, while the same code 
written in Java uses the lambda functionality which appears to return a 
singleton instance of a VM-generated class with presumably much less overhead.

Jason

From: Guillaume Laforge [mailto:glafo...@gmail.com]
Sent: Friday, March 24, 2017 4:37 PM
To: users@groovy.apache.org
Subject: Testing the Java 8 / Parrot parser online!

Hi all,

I've deployed a version of the venerable Groovy Web Console that uses the 
Parrot parser!
And we'd love if you could try it out  and report your findings.
You don't have to install anything, just go online, and run some scripts or 
classes, using Java 8 syntax constructs and APIs, and see how well it works.

I've blogged about it here:
http://glaforge.appspot.com/article/testing-java-8-snippets-on-the-new-app-engine-java-8-runtime

And you can try it here online directly, without installing anything:
https://cafe-huitre.appspot.com/

It's built with Java 8, and runs on the upcoming version of Google App Engine's 
Java runtime running on an OpenJDK 8. It's using the "indy" jar, thus with the 
invoke dynamic support automatically.

I'll deploy that version at some point to the usual web console URL, once we 
have an official release of the Parrot parser.

What we'd like is you to go and try it out :-)
Please spend a moment to try different things, and if you find any problem, 
please report them back here.

Thanks for your help!

Guillaume

--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge / 
Google+

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: improve null-handling

[Winnebeck, Jason]

(a) x ?: 0
(b) foo?.plus(bar)

Jason Winnebeck

-Original Message-
From: o...@ocs.cz [mailto:o...@ocs.cz] 
Sent: Sunday, February 19, 2017 8:38 AM
To: users@groovy.apache.org
Subject: improve null-handling

Hi there,

is there a way to make sure in Groovy

(a) that instead of "Cannot cast object 'null' with class 'null' to class 
'XXX'" for numeric primitive types XXX (like int) one gets simply a XXX 
containing 0
(b) that instead of "Cannot resolve which method to invoke for [null] due to 
overlapping prototypes" (which happens e.g., with foo+bar if foo is null) one 
gets simply null as a result of the expression?

Thanks,
OC

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: [ANNOUNCE] Apache Groovy 2.4.8 released

[Winnebeck, Jason]

Great job to the Groovy team!

One note about the announcement, the security link is 
http://groovy-lang.org/security.html.

The link http://groovy-lang.org/security.htm gives 404.

Jason

-Original Message-
From: Paul King [mailto:pa...@asert.com.au] 
Sent: Saturday, January 14, 2017 2:27 AM
To: d...@groovy.apache.org; users@groovy.apache.org; annou...@apache.org
Subject: [ANNOUNCE] Apache Groovy 2.4.8 released

Dear community,

The Apache Groovy team is pleased to announce version 2.4.8 of Apache Groovy.
Apache Groovy is a multi-facet programming language for the JVM.
Further details can be found at the http://groovy.apache.org website.

This release is a maintenance release of the GROOVY_2_4_X branch.
It is strongly encouraged that all users using prior versions on this branch 
upgrade to this version.

This release also contains critical security fixes.
Details can be found on http://groovy-lang.org/security.htm
In particular, see:
CVE-2016-6814 Apache Groovy Information Disclosure

This release includes 85 bug fixes/improvements as outlined in the changelog:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12335950

Sources can be downloaded from: http://www.groovy-lang.org/download.html
Convenience binaries, SDK and documentation can be found at:
http://www.groovy-lang.org/download.html
Jars are also available within the major binary repositories.
We would like to thank all people who contributed to this release.

Known issues

Just prior to release an issue was discovered when using final fields in 
traits. In earlier versions of Groovy, modifiers like final and transient on 
fields in traits were ignored but Groovy now honors those modifiers. 
Unfortunately, in some cases trait generation when final fields are in use is 
incorrect and will be fixed shortly. The following issue will be updated as 
this progresses:
https://issues.apache.org/jira/browse/GROOVY-8048

We welcome your help and feedback. For more information on how to report 
problems, and to get involved, visit the project website at 
https://groovy.apache.org/


Best regards,

The Apache Groovy community.

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Safe Navigation call: argument expression evaluation

[Winnebeck, Jason]

I noticed that safe navigation operator works with assignments and calls 
x?.value = 123.

But, it seems inconsistent whether or not the RHS side is evaluated. I tried a 
Groovy console where I called x?.setValue(method()) and method wasn't called, 
but in my actual app where I do x?.setValue(a.b.c) where a.b is null I get NPE. 
I found safe navigation operator documentation 
(http://groovy-lang.org/operators.html#_safe_navigation_operator), but it 
doesn't specify what happens to expressions in a method call. Is there any 
behavior I can rely upon? For now I workaround by doing an explicit x != null 
check, then x.setValue.

Jason Winnebeck

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: ClosureSignatureHint for class generic type?

[Winnebeck, Jason]

I never received a response from this, but my DSL changed slightly such that 
the closure is called with the receiving object rather than the generic 
parameter of the receiving object, and that template parameter is picked up 
properly, and in that case I can have a getter methods that return type T that 
the static compiler can pick up.

However, I noticed that there is no closure params hint that specifies this! So 
I had to make my own, if this really doesn't exist in Groovy today, I can make 
a PR someday with it (but on what branch?):

public class ThisParam extends SingleSignatureClosureHint {
@Override
public ClassNode[] getParameterTypes(MethodNode node, String[] options, 
SourceUnit sourceUnit, CompilationUnit unit, ASTNode usage) {
  return new ClassNode[] { node.getDeclaringClass() };
}
}

Jason

From: Winnebeck, Jason [mailto:jason.winneb...@windstream.com]
Sent: Tuesday, November 22, 2016 11:10 AM
To: users@groovy.apache.org
Subject: [External Source] ClosureSignatureHint for class generic type?

Suppose I have:

class Blah { void doit(Closure c) }

Used so:


Blah b = new Blah<>("abc")
b.doit {it.trim()}

Is there a ClosureSignatureHint that specifies this?

This method from DGM is what I'd want, except doit is an instance method and 
not a static one, so I can't use "FirstParam"
public static  Collection each(Collection self, 
@ClosureParams(FirstParam.FirstGenericType.class) Closure closure)

I even tried FromString, but type checker still thinks the closure takes object.

void doit(@ClosureParams(value=FromString.class, options=["T"]) Closure c)

[Static type checking] - Cannot find matching method java.lang.Object#trim(). 
Please check if the declared type is right and if the method exists.

I even tried my own hint class:

public class GenericClassType extends SingleSignatureClosureHint {
 public ClassNode[] getParameterTypes(MethodNode node, String[] options, 
SourceUnit sourceUnit, CompilationUnit unit, ASTNode usage) {
  return new ClassNode[] { pickGenericType(node.getDeclaringClass(), 0) };
 }
}

In GenericClassType hint it finds "T -> java.lang.Object". It doesn't seem to 
know about the Blah instance.

What's weird is even if I change doit to take a java.util.function.Consumer, 
it still doesn't work.

Jason
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: [VOTE] new operator ?=

[Winnebeck, Jason]

At first I was going to vote 0, because I feel like a = a ?: b is clear (and I 
compare it to a = a || b from JS). However, looking at the dev list, I 
definitely see a nice case for it:

person.name.last = person.name.last ?: "unknown"

When you have a non-trivial assignment expression, I see the benefit:

person.name.last ?= "unknown"

However, I feel like it is not intuitive or clear. But, I don't think the 
operator hurts, and it's certainly not any less intuitive than <=> for example 
or even ?: when seen for the very first time. It's an easy look up in Groovy 
docs, and if you don't know it and don't use it, it's not a huge loss. So it 
doesn't hurt to add it, and while not instantly readable, it's a trivial docs 
lookup when someone is reading the code.

So, I vote +1. But, honestly, I don't see myself using it very often as I'd 
normally use Elvis at time of initial assignment. I wouldn't put it very high 
on a prioritized backlog of things to improve for Groovy.

Jason

-Original Message-
From: Daniel Sun [mailto:realblue...@hotmail.com] 
Sent: Wednesday, November 23, 2016 10:59 AM
To: us...@groovy.incubator.apache.org
Subject: [VOTE] new operator ?=

Hi all,

 If the new operator ?=  (e.g. a ?= 'foo'  is equivalent of  a = a ?:
'foo') were to be added to Groovy programming language, do you like it?
(Yes: +1; No: -1; Not bad: 0)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/VOTE-new-operator-tp5736931.html
Sent from the Groovy Users mailing list archive at Nabble.com.

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: JDK8 Streams / Closure cast to interface

[Winnebeck, Jason]

It sounds like a good idea to support Java lambda syntax, or at least provide a 
way in Groovy to use Java lambdas. The only concern I have is that I still 
think the closure syntax is better, since you don't have parenthesis overload, 
and I still like the curly braces to distinguish that we are changing from a 
"parameter passing" context to an "expression" context. To be the lambda single 
expression syntax looks too much like parameter passing rather than defining a 
lambda.

stream.forEach((it) -> System.out.println(it))

stream.forEach{ System.out.println(it) }

I agree with Jochen about not having to create the Closure, if that is an 
option that sounds great. At first I thought it would be an observable (and 
therefore potentially breaking) change because the class would extend Closure, 
but then I realize when you pass a closure to a SAM method, the getClass is a 
java.lang.reflect.Proxy subclass instance. I have a hard time thinking that 
users would call Proxy.isProxyClass on the result, but who knows. But, I wonder 
if that potential breakage is worth it if Groovy could replace the closure that 
does not escape with a non-closure lambda (Java 8+) or non-closure inner class 
(Java 7 and earlier) when in static compilation mode. Since we know that the 
closure is to be assigned to a non-Closure type, we know setDelegate/setOwner 
can't be called, nor can setResolveStrategy. That situation should enable the 
Groovy static compiler to know whether or not use of Closure is required.

I think it's possible only under static compiler, because in dynamic mode, the 
runtime type, metaclass or runtime extension method could introduce an overload 
of the same method that takes Closure. I think only the static compiler can 
guarantee that the closure can be replaced with non-closure type without 
changing semantics (other than the change of getClass from proxy to something 
else).

Jason

-Original Message-
From: Graeme Rocher [mailto:graeme.roc...@gmail.com] 
Sent: Wednesday, November 23, 2016 6:18 AM
To: users@groovy.apache.org
Subject: Re: JDK8 Streams / Closure cast to interface

Jochen said - “If you want this really efficient, you have to skip the 
generation of the Groovy Closure instance. This is doable and I plan to do 
this, but it will be a breaking change (all open blocks would be realised using 
the same class for example, having that instance would even become optional).”

Could I recommend that since the new parser now supports the lambda syntax that 
we add to Groovy the optimised version for lambdas and keep the closure 
behaviour as is to avoid a breaking change?

This would mean that there is a visual syntactical difference between closures 
and lambdas and the behaviour of lambdas will be closer to Java thus not 
surprising folks coming from Java.

We could then keep the behaviour of closures the same as it is now without it 
being a breaking change.

Thoughts?

On Wed, Nov 23, 2016 at 11:11 AM, Jochen Theodorou  wrote:
>
>
> On 22.11.2016 19:37, Winnebeck, Jason wrote:
>>
>> I was referring to a compile-time generation of the class -- that the 
>> Closure itself that is normally generated implements the interface natively.
>
>
> Which means we are talking about direct assignments to local variables only?
> I mean the static compiler can do that in more cases, but frankly, why 
> should the static compiler even bother with creating a Closure?
>
>> That would make it equivalent to anonymous class in Java 7 and 
>> earlier for calling functional (or any SAM type) methods. That 
>> wouldn't have any problems on Android, and should be as efficient as Java 
>> without lambdas?
>
>
> Android is ok, yes. As efficient as Java without lambdas... well.. 
> that I am not sure of. Even if you make it as an anonymous inner class 
> that implements the interface and extends Closure, even if the 
> interface method will just call doCall, you will still have to pay the 
> initialization cost of the Closure, and Closure will inspect itself to 
> set the maximum parameter number for example, you will still request a meta 
> class and do some other things.
> So the init would not be as efficient. The method invocation should be 
> similar to Java, if done from Java then, since there is no dynamic 
> call. So here you would gain over todays Closure.
>
> But for typical usages of non-static Groovy the gain would be almost nil.
> Unless we can lift restrictions
>
>> I would assume the interface's method delegating to doCall would get 
>> inlined. In other words, Groovy generating code like:
>>
>> class X {
>> public static void main(String[] args) {
>> Stream.of(1).forEach(new x__closure1(X.class, X.class));
>> }
>&

RE: JDK8 Streams / Closure cast to interface

[Winnebeck, Jason]

I was referring to a compile-time generation of the class -- that the Closure 
itself that is normally generated implements the interface natively. That would 
make it equivalent to anonymous class in Java 7 and earlier for calling 
functional (or any SAM type) methods. That wouldn't have any problems on 
Android, and should be as efficient as Java without lambdas? I would assume the 
interface's method delegating to doCall would get inlined. In other words, 
Groovy generating code like:

class X {
public static void main(String[] args) {
Stream.of(1).forEach(new x__closure1(X.class, X.class));
}

private static class x__closure1 extends Closure implements 
Consumer {
public x__closure1(Object owner, Object thisObject) {
super(owner, thisObject);
}

void doCall(Integer x) {
System.out.println(x);
}

@Override
public void accept(Integer x) {
doCall(x);
}
}
}

>From Groovy: Stream.of(1).forEach { println it }

The new part being that Groovy added the accept method and implements to the 
closure it already normally would have generated, and castToType would not need 
to be called. All of the code manipulation is done at compile-time so it is 
fully STC and Android compatible, and no reflection is in use. You still have 
the a little more overhead of Closure object compared to Java static inner 
class, but I imagine this must be a lot less than proxy, but still allows 
Closure to use the owner/delegate patterns that Groovy is known for, and I 
assume would not affect backwards compatibility as superclass stays Closure.

Of course, if it were possible for compiler to determine that the closure is 
never using owner, delegate, or "thisObject", then it could be possible to drop 
the "extends Closure" entirely if it can be proven that the "closureness" of 
the object can never be observed. But that's likely not possible as any method 
taking an interface could choose to check for instanceof Closure and/or cast or 
do something special if Groovy closure is passed in -- although is that even 
possible today since Groovy actually passes in a proxy?

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Tuesday, November 22, 2016 12:01 PM
To: users@groovy.apache.org
Subject: Re: JDK8 Streams / Closure cast to interface



On 22.11.2016 15:14, Winnebeck, Jason wrote:
> I love Groovy. I also love the new streams functionality in JDK 8. 
> But, I am weary of the performance implications of Groovy + Streams, 
> because to use streams you must use Groovy closures. I see the code 
> generated creates a new closure instance then uses castToType to cast 
> the closure to the JDK8 functionality interface. Does Groovy make this 
> efficient, or is the proxy generation from this going to be excessive 
> if running a lot of small stream operations?

it is using a dynamic proxy with some optimized code paths.. such a proxy does 
for example not have to go through call to get to doCall. If you want this 
really efficient, you have to skip the generation of the Groovy Closure 
instance. This is doable and I plan to do this, but it will be a breaking 
change (all open blocks would be realized using the same class for example, 
having that instance would even become optional).

> I think an interesting feature of Groovy would be if it sees a closure 
> cast implicitly or explicitly to a certain interface type, it could 
> make the closure implement the interface.  You'd still have the 
> overhead of compile-time class generation versus lambdas, but at least 
> you wouldn't have to create proxies, and maybe there is an improved 
> chance of JIT inlining? Even if it was supported within a single 
> statement, like "Function x = {it.trim()}" or 
> Stream.of("abc").map {
> it.trim() }, the closure with trim could implement Function. Of course 
> for backwards compatibility the class could still extend Closure and 
> still implement call methods, but also implement the method apply, 
> which delegates to call.

The price question is now... is that going to be cheaper? runtime class 
generation is much more expensive than a reflective call - and considering 
Android, also much more problematic. And you have to be aware of the 
following... If I make a method call with an open block to a method taking a 
functional interface, the point in time for the conversion is after runtime 
method selection and before the actual invocation (or during invocation). At 
this point the original Closure instance already exists. Really, without test 
it is difficult to tell about the gain here

Real gains you get only with a much deeper integration

bye Jochen

ClosureSignatureHint for class generic type?

[Winnebeck, Jason]

Suppose I have:

class Blah { void doit(Closure c) }

Used so:


Blah b = new Blah<>("abc")
b.doit {it.trim()}

Is there a ClosureSignatureHint that specifies this?

This method from DGM is what I'd want, except doit is an instance method and 
not a static one, so I can't use "FirstParam"
public static  Collection each(Collection self, 
@ClosureParams(FirstParam.FirstGenericType.class) Closure closure)

I even tried FromString, but type checker still thinks the closure takes object.

void doit(@ClosureParams(value=FromString.class, options=["T"]) Closure c)

[Static type checking] - Cannot find matching method java.lang.Object#trim(). 
Please check if the declared type is right and if the method exists.

I even tried my own hint class:

public class GenericClassType extends SingleSignatureClosureHint {
 public ClassNode[] getParameterTypes(MethodNode node, String[] options, 
SourceUnit sourceUnit, CompilationUnit unit, ASTNode usage) {
  return new ClassNode[] { pickGenericType(node.getDeclaringClass(), 0) };
 }
}

In GenericClassType hint it finds "T -> java.lang.Object". It doesn't seem to 
know about the Blah instance.

What's weird is even if I change doit to take a java.util.function.Consumer, 
it still doesn't work.

Jason

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

JDK8 Streams / Closure cast to interface

[Winnebeck, Jason]

I love Groovy. I also love the new streams functionality in JDK 8. But, I am 
weary of the performance implications of Groovy + Streams, because to use 
streams you must use Groovy closures. I see the code generated creates a new 
closure instance then uses castToType to cast the closure to the JDK8 
functionality interface. Does Groovy make this efficient, or is the proxy 
generation from this going to be excessive if running a lot of small stream 
operations?

I think an interesting feature of Groovy would be if it sees a closure cast 
implicitly or explicitly to a certain interface type, it could make the closure 
implement the interface. You'd still have the overhead of compile-time class 
generation versus lambdas, but at least you wouldn't have to create proxies, 
and maybe there is an improved chance of JIT inlining? Even if it was supported 
within a single statement, like "Function x = {it.trim()}" or 
Stream.of("abc").map { it.trim() }, the closure with trim could implement 
Function. Of course for backwards compatibility the class could still extend 
Closure and still implement call methods, but also implement the method apply, 
which delegates to call.

Jason Winnebeck
Software Engineer III Contractor - IT Software Development | Windstream
600 Willowbrook Office Park, Rochester, NY 14450
jason.winneb...@windstream.com | 
windstreambusiness.com
o: 585.794-4585

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

GMavenPlus compiles stubs

[Winnebeck, Jason]

I recently encountered an error from javac compiling a stub that was otherwise 
valid from Groovy itself when I enabled generate-stubs task. I resolved the 
error properly, but I wonder, should javac be compiling stubs when using 
gmavenplus? I thought it just referred to them but did not compile them. If 
it's compiling the stubs, am I at risk of having the stub replace the 
Groovy-generated code in the final jar?

Jason Winnebeck

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: .with() variant that returns the original object

[Winnebeck, Jason]

I agree, assuming that tap is not overloaded in any other popular use or 
language, it is not likely we would want to define tap in another way. Then we 
can appease both viewpoints. The other very important reason for with(boolean, 
Closure) and tap is that unfortunately .with(boolean, Closure) will always 
trigger warning about not returning from IDE, while tap can declare 
Closure I think which hopefully can trigger IDE to say no return is 
needed?

Jason

From: Søren Berg Glasius (GR8Conf EU) [mailto:sbglas...@gr8conf.org]
Sent: Tuesday, November 15, 2016 3:51 AM
To: users@groovy.apache.org
Subject: Re: .with() variant that returns the original object

+1

I like that you provide both .with(true, Closure) and .tap(Closure)

Best regards,
Søren Berg Glasius
GR8Conf Europe organizing team

GR8Conf ApS
Mobile: +45 40 44 91 88, Web: www.gr8conf.eu, Skype: 
sbglasius
Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark
Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem

From: Guillaume Laforge 
Reply: users@groovy.apache.org 

Date: 15. november 2016 at 09.24.36
To: users@groovy.apache.org 
, Paul King 

Subject:  Re: .with() variant that returns the original object


Sounds good to me!

On Tue, Nov 15, 2016 at 9:17 AM, Paul King 
mailto:pa...@asert.com.au>> wrote:
Ok, disussion seems to have finished on this topic. I was planning to
merge Christoph's PR with minor tweaks as needed. I was going to use
'tap' as the name.

At this stage, unless I hear violent objections, I was also planning
to provide the additional variant that was discussed:

with(boolean returning, Closure closure)

so folks could use with(true) if they wanted. It's a little clunky but
is the kind of thing we do in other places within Groovy, provides an
alternative for anyone that finds 'tap' totally foreign and might also
help steer users between the two related methods.

Cheers, Paul.


On Thu, Nov 10, 2016 at 3:04 PM, Paul King 
mailto:pa...@asert.com.au>> wrote:
> On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
> mailto:jordanalexmarti...@gmail.com>> wrote:
>> What about `object.itselfWith(Closure)`? Then its understood as returning
>> the object itself but with the changes that follow.
>
> Both variants use 'itself' but only one returns 'itself', so I would
> regard that prefix as not distinguishing enough. You'd need something
> like 'withThen' or 'withReturning' to help distinguish between the
> two. The problem with 'withReturning' is that it is longer
> (character-wise) than 'with(true)' or just adding 'return it' or 'it'
> to the end of the closure - not that numbers of characters alone
> should be the most important metric.
>
> Cheers, Paul.



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge / 
Google+

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: .with() variant that returns the original object

[Winnebeck, Jason]

Regarding Jochen's 
Please don't change the existing behavior of with, that was mentioned once 
before, and it breaks backwards compatibility. I use it extensively in DSL 
code, here is a fictional DSL example that is similar in what I use it for:

def peopleWhere(Closure c) { people.findAll { it.with(c) } }

def younglings = peopleWhere { age < 35 }

In this example, I use with to avoid the extra boilerplate of cloning the 
closure and setting resolve strategy, delegate, and calling it.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, November 09, 2016 1:45 PM
To: users@groovy.apache.org
Subject: Re: .with() variant that returns the original object

On 09.11.2016 14:56, Winnebeck, Jason wrote:
> My concern about "withThis" is that it implies that "this" is the parameter 
> of the closure and not the return. We have for example withReader, 
> withWriter, withOutputStream, etc. Those all imply that the parameter is the 
> reader, the writer, the output stream. So in my mind, withThis tells me 
> nothing at all about the fact that the original object is returned. withThis 
> would not be consistent with the rest of Groovy.

I agree with this one.

> .with(returnThis:true) not only has runtime overhead, but keep in mind we are 
> comparing this to the current state today, which is .with { return this }, or 
> .with { this } depending on your style.

here I have to correct a bit though. Just want to avoid we start discussing the 
wrong thing... And I just noticed Paul made the very same mistake in the 
original post already. Well, maybe not too late yet

we are talking about

foo.with {
   return foo
}

or

foo.with {
  return it
}

not about something returning "this" at any point. "return this" would return 
neither the open block, nor foo, it would be the enclosing class instance. No 
delegate has influence about any explicit this ever.

Ah, and I did just see Jason noticed it in a later mail... well, maybe saying 
it two times is better ;)

Anyway, that´s why I think withThis and with(returnThis:true) are not good 
variants.

Also it should be noted that we already have an alias for "with", which is 
"identity". I would not want to have yet another one.

Frankly... I think we should change what it returns. It is unlikely somebody 
did depend on with returning null.

bye Jochen

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: .with() variant that returns the original object

[Winnebeck, Jason]

Yes, and the code in my e-mail is wrong, it should be .with {it} not 
.with{this}, which would end up returning the reference to the closure.

Jason

From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Wednesday, November 09, 2016 9:03 AM
To: users@groovy.apache.org
Cc: pa...@asert.com.au
Subject: Re: .with() variant that returns the original object

I agree with what Jason said. I'm still up for `tap`. We could use `with(true) 
{ ... }`, but I also dislike "with(returnThis: true) {... }" because it's not 
type safe.



2016-11-09 14:56 GMT+01:00 Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>>:
My concern about "withThis" is that it implies that "this" is the parameter of 
the closure and not the return. We have for example withReader, withWriter, 
withOutputStream, etc. Those all imply that the parameter is the reader, the 
writer, the output stream. So in my mind, withThis tells me nothing at all 
about the fact that the original object is returned. withThis would not be 
consistent with the rest of Groovy.

.with(returnThis:true) not only has runtime overhead, but keep in mind we are 
comparing this to the current state today, which is .with { return this }, or 
.with { this } depending on your style. So anything we pick needs to be shorter 
or more obvious than that, if not, then we should do nothing and just tell 
people to end the closure with "return this", or even just "this". That's why I 
would vote against .withReturnThis or .with(returnThis:true), or the equally 
cryptic .with(true).

Jason Winnebeck

-Original Message-
From: Philip Mitchell 
[mailto:pjmitch...@blueyonder.co.uk<mailto:pjmitch...@blueyonder.co.uk>]
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>; 
pa...@asert.com.au<mailto:pa...@asert.com.au>
Subject: Re: .with() variant that returns the original object

+1 for withThis()
-1 tap()

I agree with the point below. Given this is virtually identical to the existing 
with() method, the new methods name should reflect that. Consistency within 
Groovy and it’s existing libraries counts for more than consistency with what 
the method is called in another language.

I see comments below that tap() makes more sense once explained, but I would 
argue that the fact it needs explained is enough of a reason to reject it. I 
lean toward method names that clearly express what they do. tap() seem cryptic. 
The name withThis() has the virtue of being reasonably descriptive as well as 
being consistent with the existing with() method name.

Just my 2-cents worth.

Phil Mitchell


> On 8 Nov 2016, at 23:49, Paul King 
> mailto:pa...@asert.com.au>> wrote:
>
> Well we certainly could have as per Jochen's suggestion a DGM method
> roughly like:
>
> public static with(def self, boolean returnThis, Closure closure) {
> ... }
>
> and for backwards compatibility returnThis would default to false,
> i.e. with(closure) and identity(closure) are an alias for with(false,
> closure) and tap would be an alias for with(true, closure)
>
> I think it is worth having the alias, if nothing else for better type
> inferencing we'll get from the signatures but also letting people
> choose between tap and with(true).
>
> Cheers, Paul.
>
>
> On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin 
> mailto:hen...@netgate.net>> wrote:
>> +1 for withThis or withValue and +10 for Jochen's overloading
>> +proposal if
>> it's feasible.
>> -1000 for tap. Completely nonsensical to me and makes me think of
>> network tun/tap interfaces in Linux or something like that. Isn't the
>> functionality a little bit like the Builder pattern more than a pipeline of 
>> commands?
>> Maybe I'm misunderstanding the whole thing. Either way, to introduce
>> a completely new name for something that is already named and simply
>> augmented in terms of functionality seems very confusing and counter 
>> intuitive to me.
>> Imagine a Groovy newbie that reads a tutorial or reference manual and
>> first learns about with(). Then a little further on, tap() is
>> introduced. I would immediately think "why on earth did they name
>> these things completely differently, when one is essentially a
>> variant of the other???". Again, forgive me if I'm completely 
>> misunderstanding the context here.
>>
>> -Henrik
>>
>> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>>
>> Some really neat and creative suggestions here suddenly. Still happy
>> with any name, but I do like "withThis"  and "having",  However, tap
>> seems to be gaining momentum and with good reasons, despite the
>> common complaint of "What

RE: .with() variant that returns the original object

[Winnebeck, Jason]

My concern about "withThis" is that it implies that "this" is the parameter of 
the closure and not the return. We have for example withReader, withWriter, 
withOutputStream, etc. Those all imply that the parameter is the reader, the 
writer, the output stream. So in my mind, withThis tells me nothing at all 
about the fact that the original object is returned. withThis would not be 
consistent with the rest of Groovy.

.with(returnThis:true) not only has runtime overhead, but keep in mind we are 
comparing this to the current state today, which is .with { return this }, or 
.with { this } depending on your style. So anything we pick needs to be shorter 
or more obvious than that, if not, then we should do nothing and just tell 
people to end the closure with "return this", or even just "this". That's why I 
would vote against .withReturnThis or .with(returnThis:true), or the equally 
cryptic .with(true).

Jason Winnebeck

-Original Message-
From: Philip Mitchell [mailto:pjmitch...@blueyonder.co.uk] 
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org; pa...@asert.com.au
Subject: Re: .with() variant that returns the original object

+1 for withThis()
-1 tap()

I agree with the point below. Given this is virtually identical to the existing 
with() method, the new methods name should reflect that. Consistency within 
Groovy and it’s existing libraries counts for more than consistency with what 
the method is called in another language.

I see comments below that tap() makes more sense once explained, but I would 
argue that the fact it needs explained is enough of a reason to reject it. I 
lean toward method names that clearly express what they do. tap() seem cryptic. 
The name withThis() has the virtue of being reasonably descriptive as well as 
being consistent with the existing with() method name. 

Just my 2-cents worth.

Phil Mitchell


> On 8 Nov 2016, at 23:49, Paul King  wrote:
> 
> Well we certainly could have as per Jochen's suggestion a DGM method 
> roughly like:
> 
> public static with(def self, boolean returnThis, Closure closure) { 
> ... }
> 
> and for backwards compatibility returnThis would default to false, 
> i.e. with(closure) and identity(closure) are an alias for with(false, 
> closure) and tap would be an alias for with(true, closure)
> 
> I think it is worth having the alias, if nothing else for better type 
> inferencing we'll get from the signatures but also letting people 
> choose between tap and with(true).
> 
> Cheers, Paul.
> 
> 
> On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin  wrote:
>> +1 for withThis or withValue and +10 for Jochen's overloading 
>> +proposal if
>> it's feasible.
>> -1000 for tap. Completely nonsensical to me and makes me think of 
>> network tun/tap interfaces in Linux or something like that. Isn't the 
>> functionality a little bit like the Builder pattern more than a pipeline of 
>> commands?
>> Maybe I'm misunderstanding the whole thing. Either way, to introduce 
>> a completely new name for something that is already named and simply 
>> augmented in terms of functionality seems very confusing and counter 
>> intuitive to me.
>> Imagine a Groovy newbie that reads a tutorial or reference manual and 
>> first learns about with(). Then a little further on, tap() is 
>> introduced. I would immediately think "why on earth did they name 
>> these things completely differently, when one is essentially a 
>> variant of the other???". Again, forgive me if I'm completely 
>> misunderstanding the context here.
>> 
>> -Henrik
>> 
>> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>> 
>> Some really neat and creative suggestions here suddenly. Still happy 
>> with any name, but I do like "withThis"  and "having",  However, tap 
>> seems to be gaining momentum and with good reasons, despite the 
>> common complaint of "What the heck does tap mean".  I agree it makes more 
>> sense after explained.
>> 
>> Gerald R. Wiltse
>> jerrywil...@gmail.com
>> 
>> 
>> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette  wrote:
>>> 
>>> +1 for tap.  Concise and makes sense once explained (even intuitive 
>>> +to
>>> some).
>>> 
>>> Have you ever tried to find usages of with in groovy with code 
>>> examples with google without eventually loosing your temper ?
>>> 
>>> For one thing, I think tap will be easier to google for.
>>> 
>>> Marc Paquette
>>> 
>>> Le 8 nov. 2016 à 12:32, Suderman Keith  a écrit :
>>> 
>>> 
>>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou  wrote:
>>> 
>>> what about an overloaded with:
>>> 
>>> 
>>> +1
>>> 
>>> Or even something like:
>>> 
>>> myObject.with { ... } // current behaviour
>>> myObject.with(return:this) { ... } // returns this when finished.
>>> myObejct.with(return:new Object()) { ... } // returns a new Object 
>>> when finished.
>>> 
>>> This particular syntax would take a bit of extra parser arm waving 
>>> since the `return` keyword is being used differently in this context.
>>> 
>>> Keith
>>> 
>>> 
>>> myObject.with(true) {

RE: .with() variant that returns the original object

[Winnebeck, Jason]

Normally, I'd say that we should use Java as first inspiration and all other 
popular JVM languages (including Kotlin) as second inspiration, because it's 
really nice as a JVM-ecosystem developer to have a common set of terminology 
and methods. However, I agree with Paul's analysis. The meaning of "apply" 
conflicts with Java's Function.apply as well as apply from JavaScript world (I 
don't know if others agree but I think of Groovy in a similar mindset to JS). 
The closest Java signature is Function.identity, but identity is already used 
in Groovy and most think of identity function as "doing nothing".

Therefore, my vote is for tap. When I see tap it makes sense to me. It makes me 
think of the Unix "tee" shell command that does the same thing by sending the 
object to another command and returning the same output unmodified. The usage 
of tap here is also consistent with network terminology (a network tap), and 
real-world usage (such as "tapping" a water pipe). A tap observes the input 
without changing it and allowing it to pass unimpeded, unlike a filter or a 
function.

Jason

-Original Message-
From: Paul King [mailto:pa...@asert.com.au] 
Sent: Tuesday, November 08, 2016 9:34 AM
To: users@groovy.apache.org
Subject: .with() variant that returns the original object

Hi everyone,

We are hoping to release 2.5 not too far down the track. We are working on a 
revamped release process that is going to dramatically improve our ability to 
release early/release often but also comply with some additional Apache 
requirements that we follow these days.
But more on that another time.

One outstanding feature request targeted for potential inclusion in
2.5 is an alternative to .with{} that automatically returns the original object 
after executing the closure - recall that .with{} returns the last evaluated 
expression. The proposal is here:

https://github.com/apache/groovy/pull/174/files

We can't use the old name since that would break backward compatibility and is 
of utility in its current form in any case, so we are looking for a new name 
for the proposed method. If you look at the PR you will see it has been called 
'tap' and 'doto' and numerous other names have been suggested. We regard naming 
as very important and normally we'd have very strong views about suitable names 
based on functionality and similar method names within the Groovy codebase. But 
in this instance, an obvious name hasn't popped out at us, so we are requesting 
feedback from the community about what names make most sense to you.

Firstly, here is what the method does. I'll use 'tap' in these examples since 
that is what the PR currently uses but we can easily change that based on 
feedback.

myObject.tap {
// some code
}

is equivalent to:

myObject.with {
// some code
return this
}

Returning the 'self' object lends itself to various kinds of chaining, e.g.

assert [:].tap {
a = 1
}.tap {
b = 2
} == [a:1, b:2]

Or this one (adapted from a blog post[1] - and assuming you have a 
config.properties file containing answer=42 as one of the properties):

assert new Properties().tap {
new FileInputStream('config.properties').withCloseable {
load(it)
}
}.answer == '42'

Here are some of the names that have been suggested with some commentary:

dotoUsed by Clojure. Not camel case as per normal convention
(though we have upto and downto which also break that convention) and it isn't 
immediately obvious which is which between with and doto just from the names

tapComes from Ruby and a previous Groovy extension outside core
exists; meant to conjure up the idea of tapping into an object

autoWithSame as with but automatically returns self

doWith   Again, hard to distinguish between doWith and with from the
names themselves

teeAn alternative name for tap

autoA shortened version of 'autoWith'

applysame as Kotlin which has copied Groovy's with but suffers
from the downside that apply is already heavily overleaded in other contexts, 
e.g. functional programming

withThisDistinction with normal with a bit subtle perhaps

asThisDitto

withinDitto

I'll also point out the 'identity' is currently an alias for 'with', in case 
that provides any additional inspiration.

Perhaps you dis/like one of the above or have some other suggestions.
Let us know.


Cheers, Paul.


[1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Macro methods proposal

[Winnebeck, Jason]

Assuming the AST can’t already form the right signature in the JAR for IDE to 
see, I can think of one solution:

public class MacroMethods {
  @Macro public static  T safe(T param) {
def ctx = Macros.macroContext
def exp = Macros.getExpression(param)
//original code from example…
  }
}

In this case, the IDE sees a method with an appropriate signature, and knows 
the method returns the same type as the argument, but you still have access to 
the macro context via static methods which could be implemented using thread 
locals or similar. The signature could also be used to restrict the type of the 
expression allowed, although in most cases I’d expect Object or a “T” to be 
used.

Jason

From: Sergei Egorov [mailto:bsid...@gmail.com]
Sent: Friday, September 23, 2016 9:27 AM
To: users@groovy.apache.org; d...@groovy.apache.org
Subject: Re: Macro methods proposal

Hey Jason,

Left a comment on #3.

Yes, the method signature of Macro methods is not the same as the call site. 
But, for the given call site, IDE can easily determine the signature, and I'm 
pretty sure it has all the information already. Plus, this is a new language 
feature anyway, so IDE will have to support it, at least I see no other options 
for now.
See https://github.com/bsideup/groovy-macro-methods-proposal/issues/1 about the 
syntax as well

Macro methods inherit all the rules of Groovy AST transformations - they work 
only for Groovy code.

BR,
Sergei


On Fri, Sep 23, 2016 at 4:02 PM Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>> wrote:
This is a really cool idea, especially I like the idea of the compile-time 
checked ORM example. I wonder whether or not the use in simple cases is 
productive given JIT inlining and branch prediction when branching on a 
constant, and decided to phrase that question in an issue 
https://github.com/bsideup/groovy-macro-methods-proposal/issues/3.

I noticed that the method signature for the macro method does not match the 
signature used at the call site – does this confuse IDEs like IntelliJ, or does 
this actually work properly because ASTs must be in a separate JAR, so the 
@Macro AST has already run to generate a stub with the proper call signature 
that the IDE sees?

Last question, is there any interaction with Java? That is, is it possible for 
an implementation to provide a “normal” version of the method like in your 
“warn” example so that Java can call it as a normal method while in Groovy the 
transform would be applied? In that way you could make a logging library that 
would work like a normal logging library in Java but in Groovy would apply the 
macro transformations.

Jason

From: Sergei Egorov [mailto:bsid...@gmail.com<mailto:bsid...@gmail.com>]
Sent: Friday, September 23, 2016 5:58 AM
To: d...@groovy.apache.org<mailto:d...@groovy.apache.org>; 
users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Macro methods proposal

Hey, everyone.

It's been awhile since last time I participated in Groovy.
I was mostly in read-only mode for the last two years.

With this move, I hope to change it.

I created a proposal for macro methods (no ETA, initially aimed to 3.0) because 
I think they are great for the future of Groovy and compile time 
metaprogramming.

You can find the proposal here:
https://github.com/bsideup/groovy-macro-methods-proposal

Not sure how Apache people will react on it since it's on GitHub, but it was 
the simplest way for me to share and discuss it.

Please note that macro methods are not the same as MacroGroovy - another thing 
from me already merged to groovy-core. But, MacroGroovy can and should be 
implemented with macro methods.


Grammar and clearness are not my strong points, but we can improve the proposal 
altogether.


For the few years Guillaume, Baruch, Cedric and others were trying to spread 
the word  about macro methods, but the problem here that they are something 
really new and I didn't succeed explained them back in the days.


So, I'm inviting everyone to discuss them, by raising GitHub issues, or here, 
in mail list, to make them more clear for everyone, including end users.


Cheers,
Sergei
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Macro methods proposal

[Winnebeck, Jason]

This is a really cool idea, especially I like the idea of the compile-time 
checked ORM example. I wonder whether or not the use in simple cases is 
productive given JIT inlining and branch prediction when branching on a 
constant, and decided to phrase that question in an issue 
https://github.com/bsideup/groovy-macro-methods-proposal/issues/3.

I noticed that the method signature for the macro method does not match the 
signature used at the call site – does this confuse IDEs like IntelliJ, or does 
this actually work properly because ASTs must be in a separate JAR, so the 
@Macro AST has already run to generate a stub with the proper call signature 
that the IDE sees?

Last question, is there any interaction with Java? That is, is it possible for 
an implementation to provide a “normal” version of the method like in your 
“warn” example so that Java can call it as a normal method while in Groovy the 
transform would be applied? In that way you could make a logging library that 
would work like a normal logging library in Java but in Groovy would apply the 
macro transformations.

Jason

From: Sergei Egorov [mailto:bsid...@gmail.com]
Sent: Friday, September 23, 2016 5:58 AM
To: d...@groovy.apache.org; users@groovy.apache.org
Subject: Macro methods proposal

Hey, everyone.

It's been awhile since last time I participated in Groovy.
I was mostly in read-only mode for the last two years.

With this move, I hope to change it.

I created a proposal for macro methods (no ETA, initially aimed to 3.0) because 
I think they are great for the future of Groovy and compile time 
metaprogramming.

You can find the proposal here:
https://github.com/bsideup/groovy-macro-methods-proposal

Not sure how Apache people will react on it since it's on GitHub, but it was 
the simplest way for me to share and discuss it.

Please note that macro methods are not the same as MacroGroovy - another thing 
from me already merged to groovy-core. But, MacroGroovy can and should be 
implemented with macro methods.


Grammar and clearness are not my strong points, but we can improve the proposal 
altogether.


For the few years Guillaume, Baruch, Cedric and others were trying to spread 
the word  about macro methods, but the problem here that they are something 
really new and I didn't succeed explained them back in the days.


So, I'm inviting everyone to discuss them, by raising GitHub issues, or here, 
in mail list, to make them more clear for everyone, including end users.


Cheers,
Sergei

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Static type checking

[Winnebeck, Jason]

Looks like a bug to me, I can reproduce in 2.4.7. The good news is that if you 
have a method taking the Function, like:

static void calc(Function fct) { println fct.apply(10) }

Then you can call it with calc { -it }

You can use the trick to define an identity function to trick the static 
compiler:

static Function f(Function fct) { fct }
Function fct = f { -it }

However, I could not get the following signature to work:

static  Function f(Function fct) { fct }

If you don't need full type checking, the following does work:
Function fct = { Integer n ->
return 1
}

Jason

-Original Message-
From: cazacugmihai [mailto:cazacugmi...@gmail.com] 
Sent: Friday, September 02, 2016 9:06 AM
To: us...@groovy.incubator.apache.org
Subject: Static type checking

Hi, 

I have a problem running this code:
 
import groovy.transform.CompileStatic
import java.util.function.Function
 
@CompileStatic
class Test {
static void main(String[] args) {
   // this code fails 
Function fct = { Integer n ->
-n
}
 
// this one works but it is too verbose
// Function fct = ({ Integer n ->
//  -n
// } as Function)
 
println fct.apply(10)
}
}

The error:

Test.groovy: 9: [Static type checking] - Incompatible generic argument types. 
Cannot assign java.util.function.Function  to: java.util.function.Function   @ line 
9, column 36.
Function fct = { Integer n ->
  ^
1 error

[Finished in 0.5s]

Is there a bug in groovy related to @CompileStatic or maybe I am missing 
something else? I just don't want to write redundant code.

Thanks,
Mihai



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Static-type-checking-tp5735162.html
Sent from the Groovy Users mailing list archive at Nabble.com.

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Line numbers and debugging in method when branching

[Winnebeck, Jason]

Thanks Jochen, I created https://issues.apache.org/jira/browse/GROOVY-7918 for 
this issue.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Thursday, August 25, 2016 1:49 AM
To: users@groovy.apache.org
Subject: Re: Line numbers and debugging in method when branching

On 24.08.2016 23:10, Winnebeck, Jason wrote:
> Consider the following class:
>
> *class *Debugging {
> *public static void *main(String[] args) {
> *a*: *if *(args.*length *> 0) {
> *b*: println *"args"
> *}
> }
> }
>
> And let's say that I run the program with no arguments, and I put 
> IntelliJ debugger to break on line a. Now when I "step next" I see it 
> highlight line b, then step next and the program ends. The line b 
> clearly did not run. Is this a problem with IntelliJ or the bytecode?
> Below is the bytecode for the method. I'm assuming the issue is that 
> L2 is before the return, and at the return bytecode we see before it 
> LINENUMBER 4. If the return was annotated with a linenumber 5 or 6, I 
> assume the debugger would step to the closing brace of the if 
> statement (or of the method itself, depending on what was preferred). 
> Is this an issue with the IntelliJ debugger, or is it really a 
> limitation of the Groovy bytecode generation?

comparing with Java the last return should be annotated with the line with the 
closing brace of the method

> A workaround is if I put an empty return statement at the end of main, 
> the debugger works, but strangely in bytecode I see two returns.

that now is kind of a limitation of our bytecode generation

bye Jochen


This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Line numbers and debugging in method when branching

[Winnebeck, Jason]

Consider the following class:

class Debugging {
public static void main(String[] args) {
  a: if (args.length > 0) {
   b: println "args"
  }
}
}

And let's say that I run the program with no arguments, and I put IntelliJ 
debugger to break on line a. Now when I "step next" I see it highlight line b, 
then step next and the program ends. The line b clearly did not run. Is this a 
problem with IntelliJ or the bytecode? Below is the bytecode for the method. 
I'm assuming the issue is that L2 is before the return, and at the return 
bytecode we see before it LINENUMBER 4. If the return was annotated with a 
linenumber 5 or 6, I assume the debugger would step to the closing brace of the 
if statement (or of the method itself, depending on what was preferred). Is 
this an issue with the IntelliJ debugger, or is it really a limitation of the 
Groovy bytecode generation? A workaround is if I put an empty return statement 
at the end of main, the debugger works, but strangely in bytecode I see two 
returns.

  public static transient varargs main([Ljava/lang/String;)V
   L0
INVOKESTATIC Debugging.$getCallSiteArray 
()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
ASTORE 1
   L1
LINENUMBER 3 L1
ALOAD 1
LDC 0
AALOAD
ALOAD 0
INVOKEINTERFACE 
org/codehaus/groovy/runtime/callsite/CallSite.callGetProperty 
(Ljava/lang/Object;)Ljava/lang/Object;
ICONST_0
INVOKESTATIC java/lang/Integer.valueOf (I)Ljava/lang/Integer;
INVOKESTATIC 
org/codehaus/groovy/runtime/ScriptBytecodeAdapter.compareGreaterThan 
(Ljava/lang/Object;Ljava/lang/Object;)Z
IFEQ L2
   L3
LINENUMBER 4 L3
ALOAD 1
LDC 1
AALOAD
LDC LDebugging;.class
LDC "args"
INVOKEINTERFACE org/codehaus/groovy/runtime/callsite/CallSite.callStatic 
(Ljava/lang/Class;Ljava/lang/Object;)Ljava/lang/Object;
POP
   L2
RETURN
LOCALVARIABLE args [Ljava/lang/String; L0 L2 0
MAXSTACK = 3
MAXLOCALS = 2

Jason Winnebeck

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Using indy vs call-site

[Winnebeck, Jason]

You mentioned the PIC limitation of 1 in Groovy, suggesting that monomorphic 
call sites are efficient in dynamic Groovy, but not polymorphic or megamorphic 
ones. Is the call site considered polymorphic or monomorphic if the method 
called is via a common interface?

void rot90(Shape s) {
  s.rotate(90)
}

for (Shape s in (large list of squares, triangles, circles, etc.)) {
  rot90(s)
}

You mentioned that indy takes more setup for call site caching, does that imply 
that an application relying on a large number of poly/megamorphic call sites is 
better served by the pre-indy method?

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, August 24, 2016 4:02 PM
To: users@groovy.apache.org
Subject: Re: Using indy vs call-site

On 24.08.2016 20:42, Raviteja Lokineni wrote:
> Hi all,
>
> Just wanted to gather feedback on which is preferred and why? 
> benchmarks too, if any?
>
> Indy source: http://www.groovy-lang.org/indy.html
>
> I googled it up and found these:
>
>   * 
> http://stackoverflow.com/questions/29812958/execution-of-bubble-sort-is-5-times-slower-with-indy
>   * 
> http://blackdragsview.blogspot.com/2015/01/indy-and-compilestatic-as-t
> ag-team-to.html
>
> What is PIC (from the stack-overflow answer link above), I mean 
> abbreviation?

PIC means polymorphic inline cache. Example:


def foo(x) {
   x.toString() //1
}

foo(1)   //2
foo("a string")  //3
foo(1G)  //4

during runtime the places 1-4 will be call sites, places of method calls in 
this case. The callsites in 2-4 always use the same type, which is why they are 
called monomorphic. The callsite in 1 is called with 3 different types: int, 
String, BigDecimal and called polymorphic or megamorpic. The distinction is 
usually done by how many different types the polymorphic version allows before 
it turns megamorphic. A PIC is then a cache with a fast method call path for 
the n different types the PIC supports There are different approaches to this, 
so I hope I am forgiven for a little bit of oversimplification. Anyway... Java 
supports I think a PIC of 3, Groovy currently has only monomorphic versions 
or a PIC of size 1. Well, worse actually, we miss the fallback for the 
megamorphic sites. This is the same for Groovy with and without indy. 
The difference is that the setup code in indy takes much longer than the older 
callsite caching code based on runtime class generation.

But this is something which will be fixed in the future.. for indy. for the 
runtime class generation approach I am unsure

bye Jochen



This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: changing "with" to return self or doto

[Winnebeck, Jason]

In my opinion, some things should never change. It's an attribute of the 
language. If Groovy is following semver, backwards compatibility should be 
broken only in 3.x, and in my mind, you should only break backwards 
compatibility for things widely considered broken or for very major 
improvements to the language. By widely considered broken, I mean functionality 
where everyone assumes it's really supposed to do X but it actually does Y. 
When you read a list of breaking changes everyone should think for each one "oh 
I thought it already did that" or "finally, it works the way it should". Then 
there is the category similar to what JDK 9 is doing with changing/hiding 
internal classes, at least you knew it was a risk going into using that code. 
But even with that, look at how much contention that has caused around the 
Unsafe class for example. Another example is Firefox's electrolysis project to 
make Firefox multi-process, it's something that had to be done but it took 
years to make the change and breaks everyone. Java and Firefox are massive 
communities strong enough to handle that. I don't think Groovy is strong enough 
to handle that or a "Python 3" type situation.

I don't think you want to ever change basic things about Groovy like methods 
such as "with", it would break huge amounts of programs in a way that is very 
hard to test or verify. If you do that, you might as well just call it a 
different language at that point. Even things like 1/2 = 0.5 and using 
BigDecimal by default will just have to stay "forever" even if not everyone 
likes it.

Jason

-Original Message-
On 06.07.2016 16:24, Suderman Keith wrote:
> -1 to a breaking change (in 2.5 or 3.0).  I agree with Jason, breaking 
> changes only for methods that are widely considered to be broken.

if no breaking changes even in a new major version, then when?

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: changing "with" to return self or doto

[Winnebeck, Jason]

I haven't heard of doto before, but it makes sense to use a method name that 
exists in another popular and similar language if it works in exactly the same 
way. You said that doto is in Ruby, although I could only find "doto" in 
Clojure, which works as people ask for. In Ruby I found a method "tap" 
(http://seejohncode.com/2012/01/02/ruby-tap-that/). I think either can make 
sense. It's hard for me to see "doto" as two words "do to" for whatever reason 
and "tap" is more expressive of the common use case, but perhaps not as 
immediately obvious as "do to".

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, July 06, 2016 9:47 AM
To: users@groovy.apache.org
Subject: Re: changing "with" to return self or doto

and you are ok with "doto"?

On 06.07.2016 15:38, Søren Berg Glasius (GR8Conf EU) wrote:
> +1 to making a new method
>
> Best regards,
> Søren Berg Glasius
> GR8Conf Europe organizing team
>
> GR8Conf ApS
> Mobile: +45 40 44 91 88, Web: www.gr8conf.eu <http://www.gr8conf.eu/>,
> Skype: sbglasius
> Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark Personal 
> Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> --- GR8Conf - Dedicated to the Groovy Ecosystem
>
> From: Winnebeck, Jason  
> <mailto:jason.winneb...@windstream.com>
> Reply: users@groovy.apache.org <mailto:users@groovy.apache.org> 
>  <mailto:users@groovy.apache.org>
> Date: 6. juli 2016 at 15.37.21
> To: users@groovy.apache.org <mailto:users@groovy.apache.org> 
>  <mailto:users@groovy.apache.org>
> Subject: RE: changing "with" to return self or doto
>
>> My vote for whatever that's worth is never to change the way "with"
>> works, even in 3.0, or any method that is not widely considered 
>> "broken". The request feels arbitrary to me, and in that case I would 
>> defer to existing behavior. So I vote to just create a new method if 
>> that behavior is needed.
>>
>> Jason
>>
>> -Original Message-
>> From: Jochen Theodorou [mailto:blackd...@gmx.org 
>> <mailto:blackd...@gmx.org>]
>> Sent: Wednesday, July 06, 2016 9:31 AM
>> To: users@groovy.apache.org <mailto:users@groovy.apache.org>
>> Subject: Re: changing "with" to return self or doto
>>
>> I have to confess I have been testing the waters a bit ;) Anyway, I 
>> am happy we decided on not having this in 2.5. The problem of course 
>> now is if we still want it as different method like doto or self, or 
>> if we really want to push this to 3.0 and what should I do with the 
>> poor guy from the pull request? Actually starting a 3.0 branch does 
>> not look right atm too.
>>
>> On 06.07.2016 14:41, Canoo wrote:
>> > We can only make breaking changes where the old behavior was just wrong.
>> > The proposal would have been ok as well if we had started with it. But 
>> > given what we have now, it is a "won't fix".
>> >
>> > Cheers
>> > Dierk
>> > sent from: mobile
>> >
>> >> Am 06.07.2016 um 14:20 schrieb Jochen Theodorou > >> <mailto:blackd...@gmx.org>>:
>> >>
>> >> We have an overlap ofhttps://github.com/apache/groovy/pull/174 and
>> https://issues.apache.org/jira/browse/GROOVY-3976. That I would like 
>> to discuss.
>> >>
>> >> Basically 3976 is about making "with" return the object it 
>> >> operates on. Right now we have
>> >>
>> >> assert 1 == x.with {1}
>> >> assert x == x.with {it}
>> >>
>> >> and after 3976 we would have:
>> >>
>> >> assert x == x.with {1}
>> >> assert x == x.with {it}
>> >>
>> >> The mentioned pull request goes with the same logic, but using a new 
>> >> method. My opinion on this is, that we should go for a breaking change in 
>> >> 2.5 and change "with", instead of adding another method on Object.
>> >>
>> >> What do you guys think? Do you agree, or should we keep the current 
>> >> behavior, should there be a doto method instead?
>> >>
>> >> PS: just in case some people are wondering... I am trying to get some of 
>> >> our old pull requests in, there are too many and keeping them open so 
>> >> long is an insult to contributors..
>> >>
>> >> So if I do not forget about this and if there are no reactions I am going 
>> >> to change "with"
>> >>
>> >> bye Jochen
>> >
>>
>> -
>> - This email message and any attachments are for the sole use of the 
>> intended recipient(s). Any unauthorized review, use, disclosure or 
>> distribution is prohibited. If you are not the intended recipient, 
>> please contact the sender by reply email and destroy all copies of 
>> the original message and any attachments.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: changing "with" to return self or doto

[Winnebeck, Jason]

My vote for whatever that's worth is never to change the way "with" works, even 
in 3.0, or any method that is not widely considered "broken". The request feels 
arbitrary to me, and in that case I would defer to existing behavior. So I vote 
to just create a new method if that behavior is needed.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, July 06, 2016 9:31 AM
To: users@groovy.apache.org
Subject: Re: changing "with" to return self or doto

I have to confess I have been testing the waters a bit ;) Anyway, I am happy we 
decided on not having this in 2.5. The problem of course now is if we still 
want it as different method like doto or self, or if we really want to push 
this to 3.0 and what should I do with the poor guy from the pull request? 
Actually starting a 3.0 branch does not look right atm too.

On 06.07.2016 14:41, Canoo wrote:
> We can only make breaking changes where the old behavior was just wrong.
> The proposal would have been ok as well if we had started with it. But given 
> what we have now, it is a "won't fix".
>
> Cheers
> Dierk
> sent from: mobile
>
>> Am 06.07.2016 um 14:20 schrieb Jochen Theodorou :
>>
>> We have an overlap of https://github.com/apache/groovy/pull/174 and 
>> https://issues.apache.org/jira/browse/GROOVY-3976. That I would like to 
>> discuss.
>>
>> Basically 3976 is about making "with" return the object it operates 
>> on. Right now we have
>>
>> assert 1 == x.with {1}
>> assert x == x.with {it}
>>
>> and after 3976 we would have:
>>
>> assert x == x.with {1}
>> assert x == x.with {it}
>>
>> The mentioned pull request goes with the same logic, but using a new method. 
>> My opinion on this is, that we should go for a breaking change in 2.5 and 
>> change "with", instead of adding another method on Object.
>>
>> What do you guys think? Do you agree, or should we keep the current 
>> behavior, should there be a doto method instead?
>>
>> PS: just in case some people are wondering... I am trying to get some of our 
>> old pull requests in, there are too many and keeping them open so long is an 
>> insult to contributors..
>>
>> So if I do not forget about this and if there are no reactions I am going to 
>> change "with"
>>
>> bye Jochen
>

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: changing "with" to return self or doto

[Winnebeck, Jason]

I actually thought it was an expected feature of "with" to be able to return a 
value and assign it to a variable. I think it is bad to make such a breaking 
change in a 2.x version to such a fundamental method of Groovy. I use this 
extensively, especially in DSLs:

@groovy.transform.Canonical class Person { String mood; int age }

def people = [ new Person("happy", 30), new Person("sad", 20) ]

def findPeople = { c -> people.findAll { it.with(c) } }

findPeople { mood == "happy" && age > 10 }

The reason why I use with instead of setDelegate + call is that with clones the 
closure first while setDelegate modifies what was passed, which I think makes 
it not thread-safe? That's why I use "with" there.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, July 06, 2016 8:21 AM
To: users@groovy.apache.org
Subject: changing "with" to return self or doto

We have an overlap of https://github.com/apache/groovy/pull/174 and 
https://issues.apache.org/jira/browse/GROOVY-3976. That I would like to discuss.

Basically 3976 is about making "with" return the object it operates on. 
Right now we have

assert 1 == x.with {1}
assert x == x.with {it}

and after 3976 we would have:

assert x == x.with {1}
assert x == x.with {it}

The mentioned pull request goes with the same logic, but using a new method. My 
opinion on this is, that we should go for a breaking change in 2.5 and change 
"with", instead of adding another method on Object.

What do you guys think? Do you agree, or should we keep the current behavior, 
should there be a doto method instead?

PS: just in case some people are wondering... I am trying to get some of our 
old pull requests in, there are too many and keeping them open so long is an 
insult to contributors..

So if I do not forget about this and if there are no reactions I am going to 
change "with"

bye Jochen

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: For-loop vs each.

[Winnebeck, Jason]

Thanks for that update. That is not good news for me, I am very excited about 
lambdas and functional programming in Java 8+, but less excited when seeing how 
much of a performance difference there is, 30x slower in Java. Hopefully the 
situation improves in Java 9.

Jason

From: corneil.duples...@gmail.com [mailto:corneil.duples...@gmail.com]
Sent: Thursday, June 30, 2016 10:04 AM
To: users@groovy.apache.org
Subject: Re: For-loop vs each.

I did an exercise a while ago comparing imperative and functional 
implementations of FizzBuzz in various JVM languages.
It was then obvious that an imperative loop will still outperform a 
closure/lamba by a long way.

https://github.com/corneil/compare-fp




Corneil du Plessis
about.me/corneil








On 30 June 2016 at 15:44, Schalk Cronjé 
mailto:ysb...@gmail.com>> wrote:
Definitely some good information here. At least it answered the basic question 
I had.


On 30/06/2016 14:11, Winnebeck, Jason wrote:
That’s cool. I see you did it on Java 7. I wondered if for such a trivial 
example if things change in Java 8 or 9. I’ve heard that JVM can do smart 
things with stack allocation to eliminate GC and inlining. On your system you 
saw almost 4x increase. On mine I see almost 6x. However, I don’t know how well 
gbench does like JMH in terms of dead-code analysis – and this loop would 
definitely count as dead code. I also tried an example to eliminate the dead 
code.
Environment
===
* Groovy: 2.4.6
* JVM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02, Oracle Corporation)
* JRE: 1.8.0_74
* Total Memory: 214.5 MB
* Maximum Memory: 1794 MB
* OS: Windows 7 (6.1, amd64)

Options
===
* Warm Up: Auto (- 60 sec)
* CPU Time Measurement: On

user  system cpureal
Each  6271193022   25111  6271218133  6292037678
For   1107577805   20925  1107598730  1108344167
@CompileStatic:
Each  1013972638   22068  1013994706  1033565157
For2495951324566   249599698   251259849

If I change the code to do something with the result:
@groovy.transform.CompileStatic
def doEach() {{ it->
int i = 0
(1..1).each { int x -> i *= x }
println i
}}

Now the results are this:

user  system cpureal
Each  7768820885   19783  7768840668  7832590835
For834584044   11414   834595458   859830590
Jason

From: Bob Brown [mailto:b...@transentia.com.au]
Sent: Wednesday, June 29, 2016 6:28 PM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Re: For-loop vs each.


I’ve never benchmarked it,

Weirdly enough, I have!

I wrote a quick bench benchmark for just this:

http://wordpress.transentia.com.au/wordpress/2013/03/25/gorgeous-gbench/

HTH

BOB

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.




--

Schalk W. Cronjé

Twitter / Ello / Toeter : @ysb33r

RE: For-loop vs each.

[Winnebeck, Jason]

That’s cool. I see you did it on Java 7. I wondered if for such a trivial 
example if things change in Java 8 or 9. I’ve heard that JVM can do smart 
things with stack allocation to eliminate GC and inlining. On your system you 
saw almost 4x increase. On mine I see almost 6x. However, I don’t know how well 
gbench does like JMH in terms of dead-code analysis – and this loop would 
definitely count as dead code. I also tried an example to eliminate the dead 
code.
Environment
===
* Groovy: 2.4.6
* JVM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02, Oracle Corporation)
* JRE: 1.8.0_74
* Total Memory: 214.5 MB
* Maximum Memory: 1794 MB
* OS: Windows 7 (6.1, amd64)

Options
===
* Warm Up: Auto (- 60 sec)
* CPU Time Measurement: On

user  system cpureal
Each  6271193022   25111  6271218133  6292037678
For   1107577805   20925  1107598730  1108344167
@CompileStatic:
Each  1013972638   22068  1013994706  1033565157
For2495951324566   249599698   251259849

If I change the code to do something with the result:
@groovy.transform.CompileStatic
def doEach() {{ it->
int i = 0
(1..1).each { int x -> i *= x }
println i
}}

Now the results are this:

user  system cpureal
Each  7768820885   19783  7768840668  7832590835
For834584044   11414   834595458   859830590
Jason

From: Bob Brown [mailto:b...@transentia.com.au]
Sent: Wednesday, June 29, 2016 6:28 PM
To: users@groovy.apache.org
Subject: Re: For-loop vs each.


I’ve never benchmarked it,

Weirdly enough, I have!

I wrote a quick bench benchmark for just this:

http://wordpress.transentia.com.au/wordpress/2013/03/25/gorgeous-gbench/

HTH

BOB

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: For-loop vs each.

[Winnebeck, Jason]

I’ve never benchmarked it, but I assume foreach is faster because there is no 
closure class created or closure instance instantiated, or call on the call 
stack, plus it probably is easier for the JVM to optimize/inline the code when 
the loop is directly in the method. I use compile static a lot in Groovy and I 
used to use .each but always prefer the foreach loop now for the perceived 
performance difference but also because it runs much nicer in debugger (easier 
to step through in IntelliJ IDEA, better stack trace, and easier/faster to 
hotswap and less likely of JVM crash when hotswapping). For the extra few 
characters each saves, it’s not worth it. That said, I still do use each when I 
have a closure variable already (like as a parameter) or want to call a method 
reference (collection.each a.&b).

Jason

From: Schalk Cronjé [mailto:ysb...@gmail.com]
Sent: Wednesday, June 29, 2016 11:50 AM
To: users@groovy.apache.org
Subject: For-loop vs each.


This questions is NOT about style, for if it was I would settle for using 
'each' all the time. Np, this time I'm coming from a different angle. I am 
investigating backwards compatibility of Gradle plugins written in Groovy.

With Gradle 2.8, the embedded version of Groovy is 2.4.4, whereas with earlier 
2.x versions it is a Groovy 2.3.x version. This leads to an 'interesting' 
situation where one might compile a Gradle plugin using Gradle 2.13 and then 
try to run it with say Gradle 2.1. Let's start with an example first.

Normally one might do the following:

void method(Set collection)  {
collection.each { println it }
}
However if that is compiled with Groovy 2.4.x and then run with Groovy 2.3.x it 
will fail with NoSuchMethodError. This is usually due to GROOVY-6863. Most 
people will never see this as they will not usually go backwards. However in 
the Gradle situation this is real concern. So far in all cases that  I have 
seen I can work around the problem by writing

void method(Set collection)  {
for( String it in collection)  { println it }
}
This brings me to the question, whether there is any performance problem here 
or is this a fine solution?



--

Schalk W. Cronjé

Twitter / Ello / Toeter : @ysb33r

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

Dynamic type in Groovy is useful in mixing dynamic and static code. Consider 
the case of parsing a JSON/XML document, where we don't wish to develop a 
complex WSDL/JAXB/Jackson model. However the results of the parsing call 
utility methods of known types and dealing with objects of known types. In our 
case it is nice to know at compile time if I refactor a util method for 
example, that I forgot to change a call site. In the below example, we could 
statically compile the call to nameFromLanguage and the call to the new 
ProgrammingLanguage. callWebService is considered to return a "dynamic" type 
which follows standard Groovy MOP and generates standard dynamic call sites. 
The result of any property or method on a "dynamic" type is of type "dynamic", 
with the exception of methods available on all objects like toString and 
hashCode. Likewise, the parameter to "each", "collect" and such on a dynamic 
type is of "dynamic" type. But all other rules of @CompileStatic are followed. 
Bonus points if "dynamic" can be an actual type in Groovy such that you can 
have Map. Casting a dynamic type to a concrete type 
re-activates the static checking and is required to call statically-checked 
methods. A point of discussion would be if an implicit cast of "dynamic" to any 
concrete type is possible (for example when I know that "it.language" below 
must be a String) -- in this case static compiler would generate a standard 
Java cast resulting in ClassCastException if necessary. In an ideal alternate 
Groovy universe, Groovy is always statically compiled unless you define 
something with "def" in which case Groovy MOP is used (and a variant of def 
allowed on an method declaration to allow for run-time type resolution to 
totally eliminate instanceof even in "static" code by generating a synthetic 
overload taking all Object parameter that uses MOP to call the right variant).

def callWebService() {
[[language: 'Groovy', versions: [1, 2, 3]],
 [language: 'C', versions: [1, 2, 3]]]
}

//Some complex util method
String nameFromLanguage(it) { it as String }

@Immutable class ProgrammingLanguage { String name; String version }

List getProgrammingLanguages() {
List ret = []
callWebService().each {
def language = nameFromLanguage(it.language as String)
ret += it.versions.collect { version ->
new ProgrammingLanguage(name: language, version: 
version as String)
}
}
return ret
}

In terms of improvements, bug fixing is the biggest one. It is disappointing 
when I advocate strongly for Groovy then run into a static compiler bug, or 
have to put in an extra cast I shouldn't, or have to bring out a decompiler, 
none of which I've ever had to do in Java but have had to do a handful of times 
in Groovy. Yes, the improvements since CompileStatic started in 2.x to 2.4.7 
are drastic, but people have extremely high expectations of their compilers. My 
only other wish, not to any fault of Groovy team, is that I wish Groovy support 
in IntelliJ was as good as Java -- I run into bugs there from time to time. 
JetBrains is fairly responsive most of the time to Groovy defects, but there 
have been regressions (such as a near-total loss of rendering docs), and still 
currently bugs like some failures when doing basic refactoring and even in 
2016.2 since the regression of groovydoc they still have not re-fixed {@link 
abc} so any such links are simply deleted in any doc output. IDEA is in no way 
responsibility of Groovy team but I mention it as one of the three areas that 
impact the total end-to-end Groovy experience.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Monday, June 27, 2016 4:52 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

On 27.06.2016 21:47, Winnebeck, Jason wrote:
> What I'd like to see in Groovy or Kotlin is a way to be a static language but 
> declare a type as dynamic or a certain type of "dynamic" (like gpath/xml 
> where you know you are accessing map of maps).

why is as method level annotation not good enough for you?

[...]
> So now we are down to asking for improvements to the static side of Groovy so 
> we can have it all :).

and what, besides bug fixing, improvements are you thinking of?

bye Jochen

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

What I'd like to see in Groovy or Kotlin is a way to be a static language but 
declare a type as dynamic or a certain type of "dynamic" (like gpath/xml where 
you know you are accessing map of maps). Kotlin has a feature named dynamic 
type, but it doesn't work in JVM, and even if they got it to work I doubt it 
could compare to Groovy MOP. And it doesn't look like a feature they would care 
much about.

The link you posted on the Gradle group is totally on point -- "don’t create a 
tower of Babel". And that is my point for not discounting Groovy, especially 
static Groovy. Most must have Java because we have years of legacy code for 
which there is no reason to port. In general I prefer static languages and use 
them wherever possible, but see and understand the multitude of cases were 
dynamic is either far easier (duck typing/scripting), or more efficient (web 
services where you use a small part of a huge WSDL). As much as I like Kotlin, 
I like a dynamic option more. Given that 3 languages is too many (especially if 
we consider JavaScript or other frontend in many projects), and Kotlin does not 
support dynamic programming, Kotlin is out because it can't do everything 
Groovy can do. So now we are down to asking for improvements to the static side 
of Groovy so we can have it all :).

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Monday, June 27, 2016 3:23 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

On 27.06.2016 03:44, Winnebeck, Jason wrote:
> For the static side, Kotlin is a very interesting language compared to Groovy 
> looking at total new projects and teams not strongly trained in either, 
> although even in that case my intuition tells me that Groovy would be easier 
> to learn as it is more like Java -- none of the developers on my team have 
> has issues picking up Groovy especially since essentially most Java syntax 
> compiles directly as Groovy. Even as a static language, Kotlin seems a lot 
> more strict in that it wants to also enforce nullability in types, while 
> Groovy follows Java's semantics. In my mind Kotlin tries to "double down" on 
> compile-time analysis even compared to Java.

Kotlin wants to be stricter than Java, what would a static language gain from 
being less strict? The problem is with the type system, which is the core of a 
static language in the end. But if you evolve the type system, you get into 
trouble with the Java world very soon. If you limit yourself to synthetic 
sugar, you will be always in danger of being taken over by Java.

SO I can fully understand they want to make this separation between nullable 
and non-nullable types. It helps finding bugs after all, and that´s what static 
languages are for.. right?

Btw... there s something about the name Kotlin... it sounds very much like 
Kotling if not spoken out right.. then you are not at an island, but at a 
mushroom group growing on excrements. No name is perfect ;)

> But, if you have a project with dynamic and static requirements -- as far as 
> I know Kotlin has no dynamic capabilities for example to do things like gpath 
> on XML files -- now you have a dilemma if you have dynamic languages in your 
> toolbelt.

In theory a static compiler would be able to do gpath to some extend, based on 
the schema of an xml file. For things like that, you need that feature builtin 
or an extensible compiler... I have not seen an extensible compiler for Kotlin 
as of yet. But yes, I know your point.

[...]
> would I have a project mixing dynamic Groovy with static Kotlin and legacy 
> Java? Is such a thing even possible?

In practice it would probably fail at the joint compiler. To citate
https://discuss.gradle.org/t/kotlin-groovy-and-java-compilation/14903/2:
"""
  *   you can jointly compile Groovy and Java
  *   you can jointly compile Kotlin and Java
  *   you can serially compile any combination (but that means 
dependencies can only go in one direction, e.g. Java < Groovy < Kotlin) """

So possible yes, easily no. You can btw replace Groovy with Scala here and have 
the same issue. So it is not because of dynamic typing.

> If it was a hard-sell to "train a team" in two languages (Java and 
> Groovy),

yes, that´s a problem too.

> I doubt most organizations would go for Java + Groovy + Kotlin. So now I have 
> both existing project that could never (rationally) displace Groovy, and even 
> if I was starting a new project, I can't say Kotlin can do everything I'd 
> want to do in Groovy but I can say the opposite (except for the unfortunate 
> occasional static compiler bugs and occasional IDE limitations) -- that 
> Groovy can do static and it can do dynamic and it can do Java++ while Kotlin 
> only does 2 of those.

In

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

Don't discard the traction gained by the fact Kotlin only just recently reached 
1.0 stable release, and Groovy has existed for many years. I use Groovy as 
mostly a static language, but also use it for its dynamic purposes when 
interfacing with other systems, in unit and integration testing and scripting 
where I have found no other JVM language that can compare to Groovy. I started 
using Groovy in projects when 1.8 came out (I remember because the command 
chain DSL was just coming out) when Kotlin wasn't even a conception yet (as far 
as I know). So, due to age there exists a set of developers out there knowing 
Groovy as well. For the static side, Kotlin is a very interesting language 
compared to Groovy looking at total new projects and teams not strongly trained 
in either, although even in that case my intuition tells me that Groovy would 
be easier to learn as it is more like Java -- none of the developers on my team 
have has issues picking up Groovy especially since essentially most Java syntax 
compiles directly as Groovy. Even as a static language, Kotlin seems a lot more 
strict in that it wants to also enforce nullability in types, while Groovy 
follows Java's semantics. In my mind Kotlin tries to "double down" on 
compile-time analysis even compared to Java.

But, if you have a project with dynamic and static requirements -- as far as I 
know Kotlin has no dynamic capabilities for example to do things like gpath on 
XML files -- now you have a dilemma if you have dynamic languages in your 
toolbelt. In my mind, Kotlin can't do everything Groovy can do although both 
are worthy additions to Java, even if Kotlin is a little smoother on the static 
side. Now the problem is, if I can't discard dynamic -- would I have a project 
mixing dynamic Groovy with static Kotlin and legacy Java? Is such a thing even 
possible? If it was a hard-sell to "train a team" in two languages (Java and 
Groovy), I doubt most organizations would go for Java + Groovy + Kotlin. So now 
I have both existing project that could never (rationally) displace Groovy, and 
even if I was starting a new project, I can't say Kotlin can do everything I'd 
want to do in Groovy but I can say the opposite (except for the unfortunate 
occasional static compiler bugs and occasional IDE limitations) -- that Groovy 
can do static and it can do dynamic and it can do Java++ while Kotlin only does 
2 of those.

So for any team that has embraced the value of a dynamic programming tool in 
their belt, I can't see any room for Kotlin. Having static abilities in Groovy 
then handles the "Java++" component and prevents the case of saying Groovy is 
useful for only a small part of an app, because you can still get static 
benefits of refactoring and compile-time checking if you wish.

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk] 
Sent: Sunday, June 26, 2016 12:39 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

On Wed, 2016-06-22 at 14:30 +0200, Mr Andersson wrote:
> 
[…]
> I do think that's the biggest problem. Groovy was the second largest 
> JVM language in 2010, but it is not really that big anymore, mostly of 
> competition by static languages such as Scala and Kotlin.

Groovy has no serious traction in the static world. Even with the marketing 
push given by many people, including myself, Groovy has the label "dynamic" 
firmly stuck to it; it is seen in the same grouping as Clojure (and JRuby and 
Jython). When people are no discussing refactoring of codebases then if the 
base language is Java then the choice of language is Kotlin.

> People want to be able to refactor without risking of the code 
> eventually breaking totally, and that's the problem with Groovy.
> Code
> will eventually become stale and stop working if it is put on layway 
> for a while. No compile time checks is a problem for anyone interested 
> in code quality.
> 

This sounds like lazy staff misusing a dynamic language. People using Groovy 
(and Clojure) as dynamic languages tend not to have this problem.

-- 

Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

I am curious, what does JDK 9 change to affect indy?

As for switching purely to indy, I've heard a lot of issues on this list where 
people say it's slower, or at least the same. Has that changed now? It's on my 
long list to benchmark our application with indy groovy but as we use compile 
static almost exclusively so it’s not a high priority, but we use dynamic 
exclusively when producing or consuming web services where it's nice to use 
things like XmlSlurper that don't work with compile static and so indy is still 
of interest in our project.

Jason

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Thursday, June 23, 2016 2:49 AM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project



On 23.06.2016 08:00, Thibault Kruse wrote:
> On Tue, Jun 21, 2016 at 6:44 PM, Cédric Champeau 
>  wrote:
>> A strong -1 for both options. We already have 2 variants of Groovy 
>> today, indy and non indy, and in practice *nobody uses the 
>> invokedynamic version* because it's impractical to use. ...
>> Adding a new dimension, which is orthogonal to invokedynamic makes it even 
>> more complicated.
>
> How about dropping the indy version then, and instead offer a 
> statically compiled one?

actually, in the light of JDK9 we may drop the non-indy version 
unless we are happy with the callsite caching being purely reflection based

bye Jochen

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

I'd say the dynamic features of Groovy are the strongest case for Groovy right 
now, and a fully static Groovy would be a mistake because there are already 
other solutions out there for that. I'm not sure of any other language out 
there that can do what can be done with missingMethod and Closure delegates. 
For example I just wrote a Groovy script with GroovyMBean, so the ability to 
call methods that "don't exist" is very nice for integration cases.

I might see an argument that it could be possible to enhance Groovy static that 
preserves much of what Groovy dynamic offers in practice. I would say that I've 
never really used runtime metaprogramming, although I can see the case for that 
when using Groovy as a scripting engine. I've used duck typing only in one 
project before and in that case it was extraordinarily useful and I couldn't 
see another way to solve the problem (two very large independently generated 
JAXB models that had essentially the same tags). But, for almost all of the 
other cases I could see the possibility of an extension to CompileStatic that 
says if the compile-time type implements some interface X, then allow any 
method call on that, routing to a real method if exists, and invokeMethod (or 
maybe missingMethod) if it doesn't. As a test, I tried a CompileStatic program 
with GroovyInterceptable and saw that I could not call undefined methods on a 
GroovyInterceptable with CompileStatic. Anyway, in these cases I just use 
dynamic Groovy today, but if such a static compile feature existed in Groovy I 
bet it would cover the majority of cases. More precisely I am thinking about 
types like XmlSlurper's return implementing the new marker interface, and 
builders as well.

Jason

-Original Message-
From: Thibault Kruse [mailto:tibokr...@googlemail.com] 
Sent: Wednesday, June 22, 2016 3:59 AM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

I don't think the dynamic nature of Groovy is in general regarded as the 
weakest point of Groovy right now. However, I believe a fully static Groovy may 
still be preferrable than the dynamic Groovy, mostly from the point of view of 
maintaining and extending Groovy in the future, without financial sponsoring.

I would also be wary of shipping more variants of Groovy, the question to me is 
whether Groovy should just drop runtime dynamics. It would kind of stop being 
Groovy, but it might still be great.



On Tue, Jun 21, 2016 at 11:31 PM, Mr Andersson  
wrote:
>
>
> On 06/21/2016 08:08 PM, Winnebeck, Jason wrote:
>
> I would say that if you use the config script, then it would mean 
> you’d want to use @CompileDynamic on every class where you don’t want 
> static. It’s a default. I would think once you start adding logic into 
> a compiler config script like that you’ll get into trouble with users being 
> confused.
>
>
>
> I’m going to say something a little radical: if you want to use static 
> compilation all the time, you may want to consider Kotlin, which is 
> 1.0 now and similar to Groovy but is static compiled all the time. No 
> offense to Jochen and other’s amazing work that I think brought new 
> life to Groovy (I’d probably not be using it all were it not for 
> CompileStatic), I’ve encountered a handful of compiler bugs 
> unfortunately and still do from time to time, enough that I’ve learned 
> how to read Java bytecode. I still like the language features of 
> Groovy better and I haven’t found any solution other than dynamic 
> Groovy to reasonably process web services/documents though, so I still 
> like Groovy better until it’s possible to combine
> Kotlin+Groovy or Kotlin adds dynamic features. If you do use Groovy 
> Kotlin+static
> compile then make sure definitely to go with the latest 2.4.7.
>
>
> Exactly my point. I do not want to switch to Kotlin or Scala because 
> you would have to learn a new language. Groovy's power is that it is 
> so similar to Java "yet as powerful".
>
> If groovy were to make a compilestatic jar file, then it will be more 
> attractive to many requiring and liking a statically typed language.
>
> This is the weakest point of groovy right now, and it would win the 
> last argument and become a choice for those choosing a statically 
> typed JVM language, yet can go into dynamic mode on demand.
>
>
>
> Jason
>
>
>
> From: Mario Garcia [mailto:mario.g...@gmail.com]
> Sent: Tuesday, June 21, 2016 1:03 PM
> To: users@groovy.apache.org
> Subject: Re: Is it possible to enable CompileStatic for an entire 
> project
>
>
>
> If I'm not wrong, projects like Spock doesn't like @CompileStatic so 
> in case I would like to statically compile my project, at least I 
> should be 

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

I can say as someone who writes Groovy on a daily basis for about a year now on 
a project that uses CompileStatic by default on a team of 6-10 that we haven’t 
had many problems forgetting @CompileStatic or been too annoyed with it. 
Although as I’ve said in earlier post, we have forgotten once or twice and that 
did have a substantial impact. In your IDE you can even create a file template 
for Groovy class to add @CompileStatic for you. It’s not bad and IDE support 
follows. Therefore, I would say current Groovy support is good enough for those 
looking for a static language. For us using something like compiler 
configuration would just confuse things, especially since it is likely 
invisible to IDE.

Jason

From: Mr Andersson [mailto:mr.andersson@gmail.com]
Sent: Tuesday, June 21, 2016 5:31 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project


On 06/21/2016 08:08 PM, Winnebeck, Jason wrote:
I would say that if you use the config script, then it would mean you’d want to 
use @CompileDynamic on every class where you don’t want static. It’s a default. 
I would think once you start adding logic into a compiler config script like 
that you’ll get into trouble with users being confused.

I’m going to say something a little radical: if you want to use static 
compilation all the time, you may want to consider Kotlin, which is 1.0 now and 
similar to Groovy but is static compiled all the time. No offense to Jochen and 
other’s amazing work that I think brought new life to Groovy (I’d probably not 
be using it all were it not for CompileStatic), I’ve encountered a handful of 
compiler bugs unfortunately and still do from time to time, enough that I’ve 
learned how to read Java bytecode. I still like the language features of Groovy 
better and I haven’t found any solution other than dynamic Groovy to reasonably 
process web services/documents though, so I still like Groovy better until it’s 
possible to combine Kotlin+Groovy or Kotlin adds dynamic features. If you do 
use Groovy static compile then make sure definitely to go with the latest 2.4.7.

Exactly my point. I do not want to switch to Kotlin or Scala because you would 
have to learn a new language. Groovy's power is that it is so similar to Java 
"yet as powerful".

If groovy were to make a compilestatic jar file, then it will be more 
attractive to many requiring and liking a statically typed language.

This is the weakest point of groovy right now, and it would win the last 
argument and become a choice for those choosing a statically typed JVM 
language, yet can go into dynamic mode on demand.


Jason

From: Mario Garcia [mailto:mario.g...@gmail.com]
Sent: Tuesday, June 21, 2016 1:03 PM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Re: Is it possible to enable CompileStatic for an entire project

If I'm not wrong, projects like Spock doesn't like @CompileStatic so in case I 
would like to statically compile my project, at least I should be telling the 
compiler not to compile statically my specifications. Something like:

withConfig(configuration) {
source(unitValidator: { unit -> !unit.AST.classes.any { 
it.name.endsWith('Spec') } }) {
ast(CompileStatic)
}
}

my two cents
Mario

2016-06-21 18:44 GMT+02:00 Cédric Champeau 
mailto:cedric.champ...@gmail.com>>:
A strong -1 for both options. We already have 2 variants of Groovy today, indy 
and non indy, and in practice *nobody uses the invokedynamic version* because 
it's impractical to use. Typically projects depend on `groovy.jar` or 
`groovy-all.jar`, not their invokedynamic version. Adding a new dimension, 
which is orthogonal to invokedynamic makes it even more complicated. Don't 
forget that the Groovy compiler is also mixed in its runtime (which is a 
problem of its own). We should solve that first.

Second, IDEs need to know whether a file is statically compiled or not. The 
`@CompileStatic` annotation makes it very clear, and the default is the 
standard dynamic mode that has been in Groovy for more than 10 years. IDEs know 
about it, and it's simple to infer. Any alternative solution, like the config 
script, or an alternate compiler (!) makes it impossible for the IDE to guess. 
The only IDE-pragmatic solution is to have a distinct file extension for 
statically compiled Groovy files (say, .sgroovy instead of .groovy). So far 
this has been ruled out, but I think it's the most pragmatic, and IDE friendly, 
solution.



2016-06-21 18:37 GMT+02:00 Mr Andersson 
mailto:mr.andersson@gmail.com>>:

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
Tying Cédric’s advice to your previous question about gmavenplus and joint 
compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you add 
the configuration tag with a reference to your groovy script.
I also mentioned that I could not get Gmav

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

I would say that if you use the config script, then it would mean you’d want to 
use @CompileDynamic on every class where you don’t want static. It’s a default. 
I would think once you start adding logic into a compiler config script like 
that you’ll get into trouble with users being confused.

I’m going to say something a little radical: if you want to use static 
compilation all the time, you may want to consider Kotlin, which is 1.0 now and 
similar to Groovy but is static compiled all the time. No offense to Jochen and 
other’s amazing work that I think brought new life to Groovy (I’d probably not 
be using it all were it not for CompileStatic), I’ve encountered a handful of 
compiler bugs unfortunately and still do from time to time, enough that I’ve 
learned how to read Java bytecode. I still like the language features of Groovy 
better and I haven’t found any solution other than dynamic Groovy to reasonably 
process web services/documents though, so I still like Groovy better until it’s 
possible to combine Kotlin+Groovy or Kotlin adds dynamic features. If you do 
use Groovy static compile then make sure definitely to go with the latest 2.4.7.

Jason

From: Mario Garcia [mailto:mario.g...@gmail.com]
Sent: Tuesday, June 21, 2016 1:03 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

If I'm not wrong, projects like Spock doesn't like @CompileStatic so in case I 
would like to statically compile my project, at least I should be telling the 
compiler not to compile statically my specifications. Something like:

withConfig(configuration) {
source(unitValidator: { unit -> !unit.AST.classes.any { 
it.name.endsWith('Spec') } }) {
ast(CompileStatic)
}
}

my two cents
Mario

2016-06-21 18:44 GMT+02:00 Cédric Champeau 
mailto:cedric.champ...@gmail.com>>:
A strong -1 for both options. We already have 2 variants of Groovy today, indy 
and non indy, and in practice *nobody uses the invokedynamic version* because 
it's impractical to use. Typically projects depend on `groovy.jar` or 
`groovy-all.jar`, not their invokedynamic version. Adding a new dimension, 
which is orthogonal to invokedynamic makes it even more complicated. Don't 
forget that the Groovy compiler is also mixed in its runtime (which is a 
problem of its own). We should solve that first.

Second, IDEs need to know whether a file is statically compiled or not. The 
`@CompileStatic` annotation makes it very clear, and the default is the 
standard dynamic mode that has been in Groovy for more than 10 years. IDEs know 
about it, and it's simple to infer. Any alternative solution, like the config 
script, or an alternate compiler (!) makes it impossible for the IDE to guess. 
The only IDE-pragmatic solution is to have a distinct file extension for 
statically compiled Groovy files (say, .sgroovy instead of .groovy). So far 
this has been ruled out, but I think it's the most pragmatic, and IDE friendly, 
solution.



2016-06-21 18:37 GMT+02:00 Mr Andersson 
mailto:mr.andersson....@gmail.com>>:

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
Tying Cédric’s advice to your previous question about gmavenplus and joint 
compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you add 
the configuration tag with a reference to your groovy script.
I also mentioned that I could not get Gmavenplus to work, but maybe i did 
something wrong. But I literally copied and pasted that section.


Actually about 90+% of our code base in Groovy is CompileStatic I wonder if we 
should use that. Cédric, if we use the config script method, is it still 
possible to use the “skip” annotation to switch back to dynamic mode? Even if 
it worked, I highly doubt IntelliJ IDEA would know about it and think all files 
are dynamic typing so probably it’s still best for us to add @CompileStatic 
everywhere, but sometimes we forget where we wanted it. The performance 
difference is extreme when we forget it, on a certain class we missed recently 
it took our page rendering times from about 4ms to 52ms, so for us it’s an 
actual “bug” to forget to add @CompileStatic.

The problem with  the ANT task is that I don't think I can set classpath 
argumetns to the actual so passing the config location is a problem that needs 
be resolved. Not that easy with maven.

Groovy should instead provide a default GroovyStatic-2.4.4.jar file that 
enables this by default. That way everybody wins, and Groovy could join the 
club of static languages and not get rejected by those that needs to get Groovy.

It is also messy to set up config files for every maven module, although I am 
not sure. The code in that config file is also not dynamic.

withConfig(configuration) { ast(groovy.transform.CompileStatic) } and a simple 
option -compileStatic that uses an internal version of that file is preferable 
and SIMPLER.

groovyc -configscript src/con

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

The annotations also work on classes, per the documentation:

When a class is annotated, all methods, properties, files, inner classes, etc. 
of the annotated class will be type checked. When a method is annotated, static 
compilation applies only to items (closures and anonymous inner clsses) within 
the method.

Jason

From: Charles G [mailto:charl...@gmail.com]
Sent: Tuesday, June 21, 2016 11:39 AM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

If we do it the doc way:  
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
would I just use 
http://docs.groovy-lang.org/next/html/gapi/groovy/transform/CompileDynamic.html
for classes I want to be dynamic -- or is it for methods only?

Docs: 
http://docs.groovy-lang.org/next/html/gapi/groovy/transform/CompileStatic.html  
seem to make it seem like you can only use it on methods?



On Tue, Jun 21, 2016 at 7:40 AM, Thibault Kruse 
mailto:tibokr...@googlemail.com>> wrote:
I would prefer to have a codenarc rule enforcing @CompileStatic for
projects requiring it that way.

On Tue, Jun 21, 2016 at 2:38 PM, Winnebeck, Jason
mailto:jason.winneb...@windstream.com>> wrote:
> Tying Cédric’s advice to your previous question about gmavenplus and joint
> compilation, per
> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you
> add the configuration tag with a reference to your groovy script.
>
>
>
> Actually about 90+% of our code base in Groovy is CompileStatic I wonder if
> we should use that. Cédric, if we use the config script method, is it still
> possible to use the “skip” annotation to switch back to dynamic mode? Even
> if it worked, I highly doubt IntelliJ IDEA would know about it and think all
> files are dynamic typing so probably it’s still best for us to add
> @CompileStatic everywhere, but sometimes we forget where we wanted it. The
> performance difference is extreme when we forget it, on a certain class we
> missed recently it took our page rendering times from about 4ms to 52ms, so
> for us it’s an actual “bug” to forget to add @CompileStatic.
>
>
>
> Jason
>
>
>
> From: Cédric Champeau 
> [mailto:cedric.champ...@gmail.com<mailto:cedric.champ...@gmail.com>]
> Sent: Tuesday, June 21, 2016 8:29 AM
> To: users@groovy.apache.org<mailto:users@groovy.apache.org>
> Subject: Re: Is it possible to enable CompileStatic for an entire project
>
>
>
> It's in the docs:
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>
>
>
> 2016-06-21 14:24 GMT+02:00 Mr Andersson 
> mailto:mr.andersson@gmail.com>>:
>
> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat all
> Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
>
> 
> This email message and any attachments are for the sole use of the intended
> recipient(s). Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply email and destroy all copies of the original message and any
> attachments.


--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

Tying Cédric’s advice to your previous question about gmavenplus and joint 
compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you add 
the configuration tag with a reference to your groovy script.

Actually about 90+% of our code base in Groovy is CompileStatic I wonder if we 
should use that. Cédric, if we use the config script method, is it still 
possible to use the “skip” annotation to switch back to dynamic mode? Even if 
it worked, I highly doubt IntelliJ IDEA would know about it and think all files 
are dynamic typing so probably it’s still best for us to add @CompileStatic 
everywhere, but sometimes we forget where we wanted it. The performance 
difference is extreme when we forget it, on a certain class we missed recently 
it took our page rendering times from about 4ms to 52ms, so for us it’s an 
actual “bug” to forget to add @CompileStatic.

Jason

From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Tuesday, June 21, 2016 8:29 AM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

It's in the docs: 
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

2016-06-21 14:24 GMT+02:00 Mr Andersson 
mailto:mr.andersson@gmail.com>>:
Is it possible to enable CompileStatic for an entire project?

Or do you have to do it on a per class basis?

I like Groovy for some of it's features, and mostly for it's close to Java 
syntax but I would really like it to be a static language.

I've heard about Groovy++ but I believe that's dead by now, no?

Question is wether you can tell the Groovy compiler with a flag to treat all 
Groovy classes on certain paths as static?

Preferable doable from ANT too.



--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Integrating Groovy with a Java EE application and Maven

[Winnebeck, Jason]

You are trying to do joint compilation so this is the only section you need:
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation

The only difference from pure Groovy compile and joint compilation is you list 
the stub tasks to the goals. Basically all you do is add the gmavenplus-plugin 
and Groovy as a dependency.

Jason

-Original Message-
From: Mr Andersson [mailto:mr.andersson@gmail.com] 
Sent: Tuesday, June 21, 2016 3:04 AM
To: users@groovy.apache.org
Subject: Re: Integrating Groovy with a Java EE application and Maven

Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of 
compilation issues which I started to correct, but then gave up on. I shouldn't 
have to change my code to get on Groovy.

I don't remember the exact errors, but there were some.

I just tried again and it failed. I tried the join compilation but failed. 
Files were not recognized.

Plus have you seen the size of this examples page?

https://github.com/groovy/GMavenPlus/wiki/Examples

Fifty ways to configure. I don't even know anything about what I need when i 
start off, so that's just too much headache.

The ant task for me is good enough.

See comments below.

On 06/19/2016 02:09 PM, Jochen Theodorou wrote:
> On 18.06.2016 20:12, Mr Andersson wrote:
>> I was able to get it to work, both as separate groovy and java 
>> directories and as one directory ( basically a groovy directory with 
>> mixed ).
>>
>> It is interesting how complex this task was. It would appear as if 
>> the Groovy community should have figured this out by now.
>
> From the project side we support an ant task, command line and a 
> programmatic way to do joint compilation. The task is complex because 
> the build tools and the scenarios are. Gradle has much better support 
> for Groovy because we use it for our own build, but most of all, 
> because the Gradle people care.
>
>> I finally ( after 10 hours ) was able to get it to work, using only ANT.
>> The question is why Gmaven, GMaven2 Eclipse maven, and what not is 
>> even mentioned when it is as simple as an ANT task.
>
> command line is even more simple ;)

Not easy to integrate a command line argument for maven it seems. I am not sure 
how you can add that to the classpath. I was trying really hard on that but 
could not find any info, like with everything involving searching for Java 
issues. Google sucks at this, or the Java folks seriously do not ask or think 
enough about doing things the right way.

https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8

>
>> In constract, pulling in Scala and Kotlin ( during the process which 
>> I gave up on Groovy ) took seconds.
>
> well, there are some maven people, here only very few

Groovy has been alive for over 10 years. It has to be a couple of people 
wanting to integrate Groovy in a JEE environment by now.

And I doubting the procedure is different for gradle.
>
>> Relying on the Eclipse compiler is not a good thing as it has a 
>> history of breaking and not being up to date with any other compiler 
>> that one might wish to use.
>
> Which is why the page suggests gmavenplus for maven... maybe that 
> should be more clear

Did not work with both. The ant task should be the one mentioned because it 
will always succeed, unless you can figure how to add it to the classpath.

>
>> The solution ( note that I change some other things as well, like I
>> don't use src/main/java but just src ):
>>
>> 
>>  1.8
>> UTF-8
>> 4.0.6.RELEASE
>>
>>  true
>>  true
>>
>>  ${basedir}/src
>> ${basedir}/test
>> ${project.build.directory}/WEB-INF/classes
>> ${project.build.directory}/WEB-INF/classes
>> 
>>
>>
>> ${myproject.src}
>> ${myproject.src}
>>
>>  
>> ${myproject.srcOutput}
>> ${myproject.srcOutput}>
>>
>> 
>>  true
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>>  ${java.version}
>>  ${java.version}
>>
>>   false
>>  
>>
>>  
>>  
>>  default-compile
>>  none
>>  
>>  
>>  
>>  org.apache.maven.plugins
>>  maven-antrun-plugin
>>  1.8
>>  
>>  
>>  groovyc-compile
>>  compile
>>  
>>  
>>  > classname="org.codehaus.groovy.ant.Groovyc">
>>  
>>  
>>
>>  
>>  
>>  > srcdir="${myproject.src}" listfiles="true">
>>  
>>  
>>  
>>  
>>
>>  > encoding="UTF-8"/>
>>  
>>
>>  
>>  
>>  
>>  run
>>  
>>  
>>  
>> 
>
> I see, good to have that here. Now what are the main cons with this?

RE: Integrating Groovy with a Java EE application and Maven

[Winnebeck, Jason]

I work on multiple projects integrating Groovy including one large J2EE 
project. I’ve always been able to work with out of the box gmavenplus 
integration: 
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation. For 
anyone using Maven I suggest only GMavenPlus. I set up groovy-eclipse-compiler 
on some microservice projects that were created in the period after gmaven was 
discontinued and before gmavenplus. With that solution I’ve had nothing but 
problems, the plugin lagged behind official Groovy releases and the compilation 
results differed from groovyc, especially when CompileStatic was used, most 
often things would fail to compile in groovy-eclipse-compiler but work in 
groovyc, which was annoying since we developed with IntelliJ IDEA which uses 
groovyc built-in then the Maven builds would fail. Therefore we move to 
GMavenPlus whenever possible.

Jason

From: Mr Andersson [mailto:mr.andersson@gmail.com]
Sent: Monday, June 20, 2016 7:58 AM
To: users@groovy.apache.org
Subject: Re: Integrating Groovy with a Java EE application and Maven

Cons:

Requires Eclipse compiler. Big cons. Especially version < 4.4 which seems to be 
the one used by Gmaven and maven.

The ant way is just fine and is the easiest one. The cons are pretty slim if 
you ask me.

But thanks for clarifying. Now I know I have made the right decision.
On 06/19/2016 07:57 PM, Keegan Witt wrote:
I put this page together to try to explain the pros and cons of different 
tools: https://github.com/groovy/GMavenPlus/wiki/Choosing-Your-Build-Tool

-Keegan

On Sun, Jun 19, 2016 at 8:09 AM, Jochen Theodorou 
mailto:blackd...@gmx.org>> wrote:
On 18.06.2016 20:12, Mr Andersson wrote:
I was able to get it to work, both as separate groovy and java
directories and as one directory ( basically a groovy directory with
mixed ).

It is interesting how complex this task was. It would appear as if the
Groovy community should have figured this out by now.

From the project side we support an ant task, command line and a programmatic 
way to do joint compilation. The task is complex because the build tools and 
the scenarios are. Gradle has much better support for Groovy because we use it 
for our own build, but most of all, because the Gradle people care.
I finally ( after 10 hours ) was able to get it to work, using only ANT.
The question is why Gmaven, GMaven2 Eclipse maven, and what not is even
mentioned when it is as simple as an ANT task.

command line is even more simple ;)
In constract, pulling in Scala and Kotlin ( during the process which I
gave up on Groovy ) took seconds.

well, there are some maven people, here only very few
Relying on the Eclipse compiler is not a good thing as it has a history
of breaking and not being up to date with any other compiler that one
might wish to use.

Which is why the page suggests gmavenplus for maven... maybe that should be 
more clear

The solution ( note that I change some other things as well, like I
don't use src/main/java but just src ):


 1.8
 UTF-8
 4.0.6.RELEASE

 true
 true

 ${basedir}/src
 ${basedir}/test
 
${project.build.directory}/WEB-INF/classes
 
${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}

 ${myproject.srcOutput}
${myproject.srcOutput}
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}

  false
 

 
 
 default-compile
 none
 
 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 1.8
 
 
 groovyc-compile
 compile
 
 
 
 
 

 
 
 
 
 
 
 

 
 

 
 
 
 run
 
 
 


I see, good to have that here. Now what are the main cons with this?

compared with gmaven plus:
* not really integrated in maven, thus you always compile all files

compared with eclipse groovy plugin:
* stubs cannot compile as many scenarios as the integrated approach of the 
eclipse groovy compiler
* not really integrated in maven, thus you always compile all files

I am working on a new compiler tool for Groovy, which is supposed to have less 
of those disadvantages, for which I will then also look for more proper maven 
integration (I am hoping here on the help of gmaven plus). But that is still in 
the future and no fast project, because my free time is limited

bye Jochen



--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distri

RE: ShortTypeHandling castToString

[Winnebeck, Jason]

OK, I see the PR. I would be interested to hear Jochen's comments because the 
way the class is documented it looks like that class is meant to be called in 
situations with constrained conditions. I mean, doesn't the normal String cast 
in Groovy go through DefaultGroovyMethods.asType? I see in that method there is 
a specialization when casting to String that calls InvokerHelper.toString, 
which has a lot of logic in it. For your issue GROOVY-7853 around primitive 
arrays I see that asType goes to InvokerHelper.toString, which calls 
InvokerHelper.format, which sees its class "isArray()" is true, then it has a 
specialization for char[] but if it's not char[] it casts the array to a 
collection and invokes Invoker.format on that -- which seems to go through a 
lot of effort casting everything in there recursively to a String when 
everything is guaranteed to be a primitive at that point.

In that sense, even the fix provided in PR 345 doesn't match the standard 
Groovy cast to String operator, which recursively formats the elements in the 
array, instead you just use toString.

But I also wonder if the real bug is that the compiler generates 
ShortTypeHandling calls when it should be reverting to the full asType instead.

Jason

-Original Message-
From: Paul King [mailto:pa...@asert.com.au] 
Sent: Wednesday, June 15, 2016 12:32 AM
To: users@groovy.apache.org
Subject: Re: ShortTypeHandling castToString

Yes, it's clearly a bug as can be seen by running an example such as below:

String foo() { Integer }
foo() // ClassCastException

Whereas 'Integer as String' works fine. I have a fix for this in
PR#345 as part of GROOVY-7853, see:

https://github.com/apache/groovy/pull/345

Just waiting for to see if Cédric/Jochen have any comments on the other parts 
of that PR since that is an area of the codebase that I am a little less 
familiar with.

Cheers, Paul.


On Wed, Jun 15, 2016 at 1:29 AM, Winnebeck, Jason 
 wrote:
> I came across this method in Groovy 2.4.6 in ShortTypeHandling class, 
> I’ve never seen it fail but it doesn’t see right to me:
>
>
>
> public static String castToString(Object object) {
> if (object==null) return null;
> if (object instanceof Class) return (String) object;
> return object.toString();
> }
>
>
>
> How can cast to String work if the object is a Class?
>
>
>
> Jason
>
>
>
> 
> This email message and any attachments are for the sole use of the 
> intended recipient(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you are not the intended recipient, 
> please contact the sender by reply email and destroy all copies of the 
> original message and any attachments.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

ShortTypeHandling castToString

[Winnebeck, Jason]

I came across this method in Groovy 2.4.6 in ShortTypeHandling class, I've 
never seen it fail but it doesn't see right to me:

public static String castToString(Object object) {
if (object==null) return null;
if (object instanceof Class) return (String) object;
return object.toString();
}

How can cast to String work if the object is a Class?

Jason

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Looping through a hashmap & removing elements

[Winnebeck, Jason]

If you want to actually edit the original map:

def uidMap = [
  a: 123,
  b: 456,
  c: 789
]

uidMap.entrySet().removeAll { it.key.startsWith('a') }

If you want a new map, emmanuel’s solution using findAll is best.

Jason

From: Guy Matz [mailto:guym...@gmail.com]
Sent: Thursday, June 02, 2016 2:18 PM
To: users@groovy.apache.org
Subject: Looping through a hashmap & removing elements

Hi!  I want to loop through a hashmap and delete some elements based on some 
criteria . . .  I thought there would be some slick groovy method - in the 
spirit of findAll, etc. - to do this, but couldn't find it . . .  my java 
developer workmate suggested:


iter = uidMap.entrySet().iterator()
while (iter.hasNext()) {
entry = iter.next()
key = entry.key
value = entry.value

if (bla, blah, blah) {

iter.remove()

}



Is there a groovier way?



Thanks!

Guy

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Required named parameters in constructor?

[Winnebeck, Jason]

I think Groovy is limited here to the JVM's features. It is not possible to 
implement named parameters properly since you don't know the method names 
(except when using an optional compiler param in Java 1.8+), so there is not 
truly named parameters in Groovy. Instead, all of the named parameters are 
converted into a Map. And Groovy does allow positional and named parameters in 
the same call, where all of the named parameters are collected into a single 
map.

As far as I know the best solution for enforcing the named parameters is just 
to check for their presence in the map manually in the function itself.

The only place I see in Groovy where "named parameters" actually works well is 
when constructing an object -- the names parameters all turn into setter calls. 
It is possible to abuse this so that Groovy code would fail when trying to set 
non-existant parameters, but it doesn't solve the required parameters issue 
without manual code. It also has the benefit of code completion in IDE and type 
checking. Specifically I am talking about:

class FooCall {
  String a
  String b
  
  void call() {
if (!a || !b)
  throw new IllegalArgumentException("a and b are required");
println "call $a $b"
  }
}

new FooCall(a:"a", b:"b")()

However, the code is very awkward. That's not much better than:

REQ_PARAMS = ['a', 'b'] as Set
ALL_PARAMS = REQ_PARAMS + ['c'] as Set

void foo(Map params) {
  params = params ?: [:]
  if (!params.keySet().containsAll(REQ_PARAMS))
throw new IllegalArgumentException("Missing required parameters 
${REQ_PARAMS - params.keySet()}")
  if (params.keySet() - ALL_PARAMS)
throw new IllegalArgumentException("Extra parameters ${params.keySet() - 
ALL_PARAMS}")
  
  println "foo $params"
}

foo(a:1, b:1, c:1)

Jason

-Original Message-
From: David M. Karr [mailto:davidmichaelk...@gmail.com] 
Sent: Monday, April 18, 2016 1:50 PM
To: users@groovy.apache.org
Subject: Required named parameters in constructor?

First of all, I'm not attempting a "Groovy vs. anything else" argument, so put 
away the flamethrowers.  I find myself defending Groovy when I have the chance.

I was, however, reading a Ruby book, as I've never looked at it before, as I 
found I had to learn about Puppet, and I concluded that you can't work 
effectively with robust Puppet modules without understanding Ruby.

As a result, I found myself paying attention to to how Ruby features map to 
Groovy.  I'm not talking about syntax, just functional features.

I got to the point in the Ruby book where it mentioned that you could set 
particular keyword parameters (like Groovy Named Parameters) to be required.  I 
can't think of a "direct" way to map this to Groovy.  I suppose you could 
implement an "ad hoc" strategy that throws if particular values aren't set.  Is 
there a more concise way?

Just as an observation, I also note that Ruby allows mixing both "positional" 
and "named" parameters in the same constructor call.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Calling a static method by packagename.method

[Winnebeck, Jason]

Math is a class, not a package. So if you create a class jira (it really should 
at least start with a capital in Groovy, so JIRA or Jira) with static methods, 
you can access it like you do with Math. Note in your example, “import static 
java.lang.Math.*” actually is allowing you to use constants like PI without 
putting Math.PI in front – your import actually does nothing because you use 
Math.PI and Math is part of java.lang, which is a default import. Below you can 
see a proper way:

package org.matz.utils

class Jira{
  static void createTicket() {}
}

And in your script:

import org.matz.utils.* //Now you can reference any class in this package by 
its name alone, including Jira

Jira.createTicket()

Jason

From: Guy Matz [mailto:guym...@gmail.com]
Sent: Thursday, April 07, 2016 11:34 AM
To: users@groovy.apache.org
Subject: Calling a static method by packagename.method

Hello!  I have some static methods defined and am able to access them after I 
import, e,.g.
import static org.matz.utils.jira.*

With that import I can call the methods, e.g. createTicket, but I would like to 
be able to call it as jira.createTicket, as is possible with the Math package, 
e.g.

import static java.lang.Math.*
println "PI is ${PI} (${Math.PI})"

my method declaration in jira.groovy is (including the namespace):
package org.matz.jenkins

def static void createTicket(String changelog, String summary, Map config) { 
... }

Does anyone know what I need to do to either my definitions, or import, or 
something else to be able to refer to the createTicket method as 
jira.createTicket?  I would like to be able to do this to avoid name collisions 
as well as to be able to make explicit which "class" I'm calling the method on.

Thanks!
Guy


--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Can anyone comment on this stackoverflow posting that indicates XmlSlurper is actually namespace aware by default

[Winnebeck, Jason]

After seeing this a few times now, including being bit by it myself and my work 
team, I have submitted a JIRA and PR to remove the 4 confusing characters from 
the Javadoc :).

https://issues.apache.org/jira/browse/GROOVY-7810  XmlSluper default 
constructor documentation about namespace aware incorrect.
https://github.com/apache/groovy/pull/305  GROOVY-7810 fix XmlSlurper default 
ctor doc

I posted answer to SO explaining the situation 
http://stackoverflow.com/a/36435993/3875382

Jason

-Original Message-
From: garneke [mailto:kenton.gar...@issinc.com] 
Sent: Tuesday, April 05, 2016 3:59 PM
To: us...@groovy.incubator.apache.org
Subject: Re: Can anyone comment on this stackoverflow posting that indicates 
XmlSlurper is actually namespace aware by default

Here is an unsophisticated example…

testparse.groovy
  



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Can-anyone-comment-on-this-stackoverflow-posting-that-indicates-XmlSlurper-is-actually-namespace-awat-tp5732204p5732207.html
Sent from the Groovy Users mailing list archive at Nabble.com.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Hierarchy of singletons howto?

[Winnebeck, Jason]

I think it's reasonable to have two singletons related by hierarchy. My guess 
is that the AST is making a private constructor, which makes the class closed 
for extension. A possible workaround would be to make a base class equal to Foo 
that is not a Singleton, then a Foo extends Base and Bar extends Base as 
Singleton (or use an interface).

Jason

-Original Message-
From: OC [mailto:o...@ocs.cz] 
Sent: Friday, April 01, 2016 3:39 PM
To: users@groovy.apache.org
Subject: Re: Hierarchy of singletons howto?

At least one of us two must have missed something in Object-Oriented-101.

There is exactly one instance of class Foo.

And there is exactly one instance of class Bar, whose functionality is derived 
from Foo.

Consider the factory pattern: there are two related classes, A and B extends A. 
If it so happens that each of them needs a factory class, then is is 
self-evident that

(a) both AFactory and BFactory need to be singletons (as any factory out there)
(b) BFactory should extend AFActory, for just as B's functionality extends A's 
functionality, the same applies for their factories.

And one can implement the functionality easily, e.g., using

===
class Foo {
  static instance=newInstance()
}
class Bar extends Foo {
  static instance=newInstance()
}
===

it works like a charm, only -- unlike @Singleton -- it is not lazy (and if 
turned to lazy, it would not be threadsafe).

Thanks and all the best,
OC

On 1. 4. 2016, at 11:48, Alessio Stalla  wrote:

> Your requirement is logically inconsistent. If there is only one possible 
> instance of Foo, there cannot be /another/ instance of Foo which is also a 
> Bar.
> 
> On 1 April 2016 at 04:28, OC  wrote:
> Hello there,
> 
> how do you make a hierarchy of classes, each of which happens to be a 
> singleton?
> 
> The naïve solution simply does not work:
> 
> ===
> 85 /tmp>  @Singleton class Foo { }
> @Singleton class Bar extends Foo { }
> 
> println "Foo: ${Foo.instance}, Bar: ${Bar.instance}"
> 86 /tmp> groovy qq
> Caught: java.lang.IllegalAccessError: tried to access method Foo.()V 
> from class Bar
> java.lang.IllegalAccessError: tried to access method Foo.()V from class 
> Bar
> at Bar.(qq.groovy)
> at Bar.(qq.groovy)
> at qq.run(qq.groovy:4)
> 87 /tmp>
> ===
> 
> What is the proper way to achieve this?
> 
> Thanks a lot,
> OC
> 
> 

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: interface/implementation patten (was: Proxying how to?!?)

[Winnebeck, Jason]

In Java 8+, interfaces can have static methods, and with default methods, you 
can simulate multiple inheritance. To be honest, I'm not sure how/if you can 
use this from Groovy -- if Groovy interface can define static or default 
methods. In the case of conflicts, Java forces you to override the shared 
method. From the override you can call one of the super class versions if you 
want.

public interface Foo {
static String getFoo() {
return "Foo";
}

default String foo() {
return getFoo();
}

default String shared() {
return foo();
}
}

public interface Bar {
default String bar() {
return "Bar";
}

default String shared() {
return bar();
}
}

public class FooBar implements Foo, Bar {
public static void main(String[] args) {
FooBar fooBar = new FooBar();
System.out.println(fooBar.foo());
System.out.println(fooBar.bar());
System.out.println(fooBar.shared());
}

@Override
public String shared() {
return Foo.super.shared();
}
}

Jason

-Original Message-
From: OC [mailto:o...@ocs.cz] 
Sent: Wednesday, March 30, 2016 12:59 PM
To: users@groovy.apache.org
Subject: interface/implementation patten (was: Proxying how to?!?)

Oh, by the way,

On 30. 3. 2016, at 17:12, Jochen Theodorou  wrote:
> This again forces people to split their classes in interfaces and 
> implementations

reminded me another question of mine. I actually want to embrace this pattern 
for a long time (after all, I am used to it from ObjC), but there are two 
problems:

(a) interfaces cannot contain static methods

I am afraid there would be no solution at all in Java-based world, or does 
Groovy bring some?

(b) they force me to maintain two parallel hierarchies, like

===
interface Foo {
  def foo();
  ...
}
class Foo_Implementation implements Foo {
  def foo() { ... }
  def myfoo() { ... }
  ...
}
interface Bar implements Foo {
  def bar();
  ...
}
class Bar_Implementation extends Foo_Implementation implements Bar {
  def bar() { ... }
  ...
}
===

with a high danger of a mistake leading to inconsistence of these two 
hierarchies. Not speaking of the factory pattern to replace those pesky static 
methods, which would, alas, add a third hierarchy for factories; if I wanted to 
use interface/implementations for factories too, I get _four_ parallel 
hierarchies, which need to keep consistent! Quadruple ick.

Is there some trick in Groovy which makes this task groovier (or at the very 
least reasonably manageable), or am I up to my own source preprocessor and/or 
ASTTs (which again would clash with traits :/ )?

Thanks a lot,
OC

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Proxying how to?!? (was: changing dynamically the name of classes in a source code)

[Winnebeck, Jason]

You still have to follow the rules of Java bytecode, that is your class 
DumbProxy is not related by class hierarchy or interface to AnyClassOfMine, so 
you can't cast to it. You have to use def/Object type and Groovy's duck typing, 
or you need to make DumbProxy extend AnyClassOfMine or make an interface for 
them both to implement and use that.

Other options to consider include:
http://docs.groovy-lang.org/latest/html/gapi/groovy/util/Proxy.html
http://docs.groovy-lang.org/latest/html/gapi/groovy/util/ProxyGenerator.html
http://docs.groovy-lang.org/latest/html/gapi/groovy/lang/Delegate.html

Jason

-Original Message-
From: OC [mailto:o...@ocs.cz] 
Sent: Tuesday, March 29, 2016 12:16 PM
To: users@groovy.apache.org
Subject: Proxying how to?!? (was: changing dynamically the name of classes in a 
source code)

Incidentally...

On 28. 3. 2016, at 18:10, OC  wrote:
> completely absurd and very anti-object-oriented) "Cannot cast object" 
> exception.

... this reminded me of a problem I so far haven't been able to find a proper 
solution for: how the heck do you proxy in Groovy?

In ObjC, I can write

===
@interface AnyClassOfMine:Beanlike
@property NSString *name;
@end
@implementation AnyClassOfMine @end

@interface DumbProxy:Beanlike
@property id server;
@end
@implementation DumbProxy
-forwardingTargetForSelector:(SEL)sel { return self.server; }
@end

id objects=@[[AnyClassOfMine new:@"name":@"Direct"],[DumbProxy 
new:@"server":[AnyClassOfMine new:@"name":@"Proxied"]]];
for (AnyClassOfMine *o in objects) NSLog(@"got %@",o.name);
===

and it works precisely as assumed, writing out

===
2016-03-29 17:57:37.501 a.out[5387:707] got Direct
2016-03-29 17:57:37.503 a.out[5387:707] got Proxied
===

(Note if interested: the Beanlike superclass is irrelevant, it just simulates 
the new Foo(bar:bax) functionality of Groovy, which ObjC does not have, by 
implementing the new:(property-name):(value) method.)

Groovy -- unlike pure Java -- is smart enough to allow me to _implement_ such a 
proxy, but for sweet world, I cannot find a way to _use_ it?

===
class AnyClassOfMine {
  def name
}

class DumbProxy {
  def server
  def propertyMissing(String name) {
server."$name"
  }
}

def objects=[new AnyClassOfMine(name:"Direct"),new DumbProxy(server:new 
AnyClassOfMine(name:"Proxied"))]
for (AnyClassOfMine o in objects) println "got $o.name"
===

Alas, instead of working as expected, this fails with the aforementioned 
nonsensical exception:

===
got Direct
Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot 
cast object 'DumbProxy@73f43791' with class 'DumbProxy' to class 
'AnyClassOfMine'
...
===

How do you write and use a proxy in Groovy, so that it works properly?

(Note: "for (o in objects) ..." would work is this case, but would bring other 
problems, e.g., if there was a method "foo(AnyClassOfMine obj)" called as "for 
(o in objects) foo(o)", it would cause "No signature of method is applicable 
for argument types: (DumbProxy)".)

Thanks a lot,
OC

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: search for particular text in a multi-line string

[Winnebeck, Jason]

Contains works, but depending on your situation you might need to normalize 
data. If you don't know where your line breaks are, for example if you want to 
find "the cow jumped over the moon" but the string is "I read a book. It is 
called the Cow\nJumped Over the Moon", in this case you need to normalize the 
input. You can normalize any sequence of whitespace (including newlines) to a 
single space and do a case insensitive comparison (or convert everything to 
lower case).

Jason

From: Deng, Lea [mailto:lea.d...@ccc.govt.nz]
Sent: Wednesday, March 16, 2016 12:29 AM
To: 'users@groovy.apache.org' 
Subject: search for particular text in a multi-line string

I'd like to have your suggestions on searching for particular text in a 
multi-line string.

I found the contains() method does not work:
boolean isContain = multi_line_String.contains(expectedText)

Do I have to break down my multi line string into single lines for the search? 
I think that may slow down the search.

Or is there an object I could use to declare the multi line, instead of using 
String?

many thanks,
Kind Regards
Lea Deng

Creating connections to make IT easier for everyone

Lead Test Analyst
IT Regulatory Services Team
Christchurch City Council
New Zealand
DDI: +64 (3) 941 88 55
Extn: 8855
lea.d...@ccc.govt.nz


**
This electronic email and any files transmitted with it are intended
solely for the use of the individual or entity to whom they are addressed.

The views expressed in this message are those of the individual sender
and may not necessarily reflect the views of the Christchurch City Council.

If you are not the correct recipient of this email please advise the
sender and delete.

Christchurch City Council
http://www.ccc.govt.nz
**

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy Console wont start

[Winnebeck, Jason]

Are you calling groovyStart directly? That script takes a built program as a 
parameter (like one you build). If you want to run Groovy Console that comes 
with Groovy, you need to run groovysh.bat (for command line version) or 
groovyConsole.bat (for GUI version).

Jason Winnebeck

-Original Message-
From: Mart [mailto:m.a...@herts.ac.uk] 
Sent: Friday, March 18, 2016 6:51 AM
To: us...@groovy.incubator.apache.org
Subject: Groovy Console wont start

As anew green user can anyone help me getting the Groovy Console  2.4.6 to
fire up.

I have very little knowledge of Java so Im look for detailed help.

I have looked at the startGroovy.bat placing pauses in the code and found
where it fails but I don’t have the knowledge to go further.

There is a problem somewhere here, the paths exist

"C:\Java\jdk\bin\java.exe" 
"-Xmx128m" 
-Dprogram.name="" 
-Dgroovy.home="C:\Program Files (x86)\Groovy\Groovy-2.4.6" 
-Dtools.jar="C:\Java\jdk\lib\tools.jar" 
-Dgroovy.starter.conf="C:\Program Files
(x86)\Groovy\Groovy-2.4.6\conf\groovy-starter.conf" 
-Dscript.name=""  
-classpath "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\lib\groovy-2.4.6.jar" 
org.codehaus.groovy.tools.GroovyStarter 
--main  
--conf pause

This is the Java error below at the Bottom

Press any key to continue . . .
at have_JAVA_HOME
Press any key to continue . . .
at valid_JAVA_HOME_DIR
Press any key to continue . . .
at valid_JAVA_HOME
Press any key to continue . . .
at check_GROOVY_HOME
Press any key to continue . . .
at execute
Press any key to continue . . .
at after_cp
Press any key to continue . . .
groovy_opts="-Xmx128m" -Dprogram.name="" -Dgroovy.home="C:\Program Files
(x86)\G
roovy\Groovy-2.4.6" -Dtools.jar="C:\Java\jdk\lib\tools.jar"
-Dgroovy.starter.con
f="C:\Program Files (x86)\Groovy\Groovy-2.4.6\conf\groovy-starter.conf"
-Dscript
.name=""
Press any key to continue . . .
"C:\Java\jdk\bin\java.exe" "-Xmx128m" -Dprogram.name=""
-Dgroovy.home="C:\Progra
m Files (x86)\Groovy\Groovy-2.4.6" -Dtools.jar="C:\Java\jdk\lib\tools.jar"
-Dgro
ovy.starter.conf="C:\Program Files
(x86)\Groovy\Groovy-2.4.6\conf\groovy-starter
.conf" -Dscript.name=""  -classpath "C:\Program Files
(x86)\Groovy\Groovy-2.4.6\
lib\groovy-2.4.6.jar" org.codehaus.groovy.tools.GroovyStarter --main  --conf
pau
se
java.lang.ClassNotFoundException: --conf
at
org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:179)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java
:99)
at
org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)
Press any key to continue . . .







--
View this message in context: 
http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981.html
Sent from the Groovy Users mailing list archive at Nabble.com.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy Console wont start

[Winnebeck, Jason]

I understand you are green that's fine.

I don't use the installer, so I didn't have groovyConsole.exe, but I did try 
the installer. My account is not an admin so I installed outside of Program 
Files, and for whatever reason I got no start menu entries, but all of the 
files did copy down. If I run groovyConsole.exe directly it did work. I'm not 
sure how groovyConsole.exe differs from the bat in terms of launching Groovy, 
or how the exe file is made.

Jason

-Original Message-
From: Mart [mailto:m.a...@herts.ac.uk] 
Sent: Friday, March 18, 2016 8:47 AM
To: us...@groovy.incubator.apache.org
Subject: RE: Groovy Console wont start

Thanks Jason

Told you I was green

The windows insall added  Start GroovyConsole to the start menu the properties 
being "C:\Program Files (x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".

However running the GroovyConsole.bat does indeed start up the console. At 
least I know my Java_Home is ok!

Any idea why groovyConsole.exe doesnt run?

Mart



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
Sent from the Groovy Users mailing list archive at Nabble.com.

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Very Odd/Random JVM Slowdown With Indy

[Winnebeck, Jason]

Method handles are a relatively new component to the JVM. One thing to consider 
is whether or not you are running the latest JVM version.

If I ignore for a moment your finding of that method on the top of the stack, 
when I’ve seen the JVM get very slow without any apparent deadlocks I’ve also 
seen GC as an issue. I would just double check to make sure there’s not a leak 
(in heap or permgen/metaspace) going on, it might be possible that the 
MethodHandle code is more susceptible to GC pauses and appears more often in 
your stack dumps. Same thing with your underlying OS as well, I would just 
double check that you aren’t in a swap condition or (on Linux) in iowait 
states. Your note about removing indy fixing this seems to suggest that is not 
the case but it’s also a common condition I see with “JVM starts running order 
of magnitudes slower until you restart” issues. It may also be possible that 
Groovy indy or JVM invokedynamic has a leak that shows up as a memory scaling 
problem as well.

Jason

From: David Clark [mailto:plotinussm...@gmail.com]
Sent: Monday, March 14, 2016 5:31 PM
To: users@groovy.apache.org
Subject: Very Odd/Random JVM Slowdown With Indy

I've been chasing a slowdown in our application for a couple of months now. I 
have what I believe is a solution (no slowdown for 4 days now). But I'm having 
difficulty understanding why the solution works.

Symptoms:

At random intervals and a random times our web servers will go from serving 
responses in the 300 ms range to taking 30 seconds or more. Sometimes the 
servers will recover, sometimes they require a restart of the webserver (spring 
boot/tomcat). When the applications slow down we always see the tomcat thread 
pool hit the maximum size. Every single thread in the thread pool is in the 
RUNNABLE state but appears to be making no progress. Successive thread dumps 
show that the stacks are changing, but VERY slowly. The top of the stack is 
always this method:

at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native Method).

The other common condition is that whatever application code is on the stack is 
always dynamically compiled. Code that is @CompileStatic is NEVER on the stack 
when we see these slowdowns.

The thread dumps showed that the application code is never waiting on locks, 
socket reads, db connections, etc.

Solution:

The solution to the problem was to disable Indy compilation and return to 
non-Indy compilation. However, I don't think Indy is the problem here. I 
noticed that our Spring Boot executable jar contained BOTH groovy-all-2.4.5.jar 
AND groovy-all-indy-2.4.5.jar. Someone forgot to exclude the non-indy jars.

My theory:

Having both indy and non-indy jars on the classpath is confusing the JIT 
compiler. Code will be continuously JIT-ed as different methods fight over 
which class files to JIT, those loaded from the groovy-all jar or those loaded 
from the groovy-all-indy jar. If this is true then the compiler threads will be 
continuously running and applying native locks which are invisible to tools 
like VisualVM. The result would be random slowdowns because only certain 
combinations of code paths would result in slowdowns. It would also cause 
application code to go very slowly as the JIT compiler continuously re-compiles 
code over and over again. Application code would be stuck mostly waiting for 
JIT operations to complete as invalidated code is continuously removed and 
replaced.

For now I will be leaving Indy disabled until we can do more accurate load 
testing in non production environments.

My Question:

Is this theory possible? Am I going in a direction that is possible or likely?

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Failing to change the value of a Java variable from wihtin a Groovy script (potential issue?)

[Winnebeck, Jason]

Unfortunately static compile can be pretty flaky at times and I run into bugs 
often with it and have to redesign code. For small scripts I would advise 
against it (if you need type checking, use TypeChecked). I'm wondering if the 
script is getting compiled to get field x from the base class but favors 
setting binding.x = 'two' in the script.

I would try without static compilation and see if it works. If it does work 
without static compilation, upgrade to the very latest Groovy (2.4.6) as bugs 
are fixed in static compiler all the time. If that doesn't fix the problem, 
then change the Java field to private and create a getX() and setX(String). If 
that doesn't work and you still need static compile, try an explicit 
setX('two') or this.x = 'two' in the script. Historically the static compiler 
has been more reliable when you are more explicit.

Jason

From: Thierry Hanser [mailto:thierry.han...@lhasalimited.org]
Sent: Tuesday, March 08, 2016 11:32 AM
To: 'users@groovy.apache.org' 
Subject: Failing to change the value of a Java variable from wihtin a Groovy 
script (potential issue?)

Hi,

The following very simple code is behaving really strangely.
Could anyone please tell me if this is an issue in Groovy or something I am not 
doing properly (I would like to vote for the latter, yet...).

In Java

x='one';
System.out.println("init x: " + x);

In Groovy

println '1 = ' + x
x = 'two'
println '2 = ' + x

Output:

init x: one  <- initial value assignement OK

1 = one  <- successfully accessing 'x' from within the compiled script OK
the Groovy script has picked up the value of the Java variable;
the implicit getX() has been called

2 = one<- should be 'two' as per Groovy code (second line)
but is unchanged ???

It seems that the Groovy script can't change the value of 'x' (can't access 
setX()). However there is no compilation error ('x' is not read-only)
When implementing getX/setX methods, only the getter is called (in both print 
statements, line 1,3) but during the assignment instruction (line 2), the 
setter is silently ignored (the value of 'x' remains 'one' instead of 'two'.

The Java/Groovy binding is operational since the 'one' value of 'x' in the Java 
 base class is successfully retrieved. So could anyone please tell me where the 
issue is?
The confusing part is that even within in the Groovy context alone, the 
assignment 'x='two' is not honoured (and yet there are no compilation/runtime 
error)

Note that I tried all combinations of setters/getters/visibility and can at the 
best read but never modify the variable 'x'. The same behaviour occurs with 
using the GroovyScriptEngine or GroovyClassLoader

Thank you very much in advance for your help.

Thierry
-

PS: (I am not sure if my previous message went through as I was still in the 
mailing list registration process, apologies if it is a duplicate)

Full code:

import org.codehaus.groovy.control.CompilerConfiguration;
import org.codehaus.groovy.control.customizers.ASTTransformationCustomizer;

import groovy.lang.Binding;
import groovy.lang.Closure
import groovy.lang.GroovyClassLoader;
import groovy.lang.GroovyShell;
import groovy.transform.CompileStatic;;

abstract class GroovyDemoScript extends Script
{
public String x;

public GroovyDemoScript()
{
   x='one';
   System.out.println("init x: " + x);
}

public static void main(String...args) throws Throwable
{
   
   // Compilation configuration
   CompilerConfiguration configuration = new CompilerConfiguration();
   configuration.addCompilationCustomizers(new 
ASTTransformationCustomizer(CompileStatic.class));

// make sure we use the Java base class where 
'x' is defined
   configuration.setScriptBaseClass(GroovyDemoScript.class.name);

   GroovyShell shell = new 
GroovyShell(this.getClass().getClassLoader(), new Binding(), configuration);

   // source code
   String scriptSource= "println '1 = ' + x; x = 'two'; println '2 = ' 
+ x\n";

   // compile the source code and run the compiled script
   GroovyDemoScript compiledScript = shell.parse(scriptSource);
   compiledScript.run();
}
}


Switchboard: +44 (0)113 394 6020
Technical Support: +44 (0)113 394 6030

Lhasa Limited, a not-for-profit organisation, promotes scientific knowledge & 
understanding through the development of computer-aided reasoning & information 
systems in chemistry & the life sciences. Registered Charity Number 290866. 
Registered Office: Granary Wharf House, 2 Canal Wharf, Leeds, LS11 5PS. Company 
Registration Number 01765239. Registered in England and Wales.
This communication, including any associated attachments, is intended for the 
use of the addressee only and may contain confidential, privileged or copyright 
mater

RE: building a jar from groovy script with gradle

[Winnebeck, Jason]

I've "deployed" some scripts to other users in my organization where Java but 
not Groovy is installed through the GroovyWrapper script. I got it from 
Codehaus and I can't find the original copy anywhere but I found a fork of it 
at https://github.com/sdanzan/groovy-wrapper that appears to have more features 
than the original. The original I have basically just uses the Ant inside of 
the Groovy distribution to compile a single Groovy file and merge that file, 
embeddable groovy JAR and some of the Groovy libs into a single jar you can run 
with java -jar.

Looking at the code it appears the main difference in that updated script is 
that it supports adding @Grab'd dependencies into the single JAR, presumably to 
prevent users from having to download them.

Jason

-Original Message-
From: Jim Northrop [mailto:james.b.north...@googlemail.com] 
Sent: Tuesday, March 08, 2016 8:19 AM
To: users@groovy.apache.org
Subject: Re: building a jar from groovy script with gradle

Out of interest, what is the typical deployment strategy for a runnable Groovy 
class w/main method? I have been trying to make a user executable jar but as 2 
diff.jars. One jar is only my code, no support jars and 2nd is 
mystuff-all-v1.0.jar as a bundle w/all dependency jars included hence runnable. 
End user can choose jar. 

 Are there other strategies to package code 4 deployment? 
Thx.

Sent from my iPad

> On 8 Mar 2016, at 11:45, Schalk Cronjé  wrote:
> 
> I can spot a number of issues in your Gradle script, howver I need to 
> understand context.
> 
> [1] Are you trying to put a single Groovy script + required Groovy JARs into 
> a JAR?
> 
> OR
> 
> [2] Are you trying to build a proper Groovy application consisting of a 
> coouple of class files en dependent JARs?
> 
>> On 08/03/2016 10:33, Raphael Bauduin wrote:
>> 
>> Hi,
>> 
>> I'm trying to package a groovy script as a jar with the help of 
>> gradle, I use this gradle config: http://pastebin.com/RFEhzMCp
>> 
>> it builds fine, but when I try to run it with java -jar path_to.jar I 
>> get this error:
>> Error: A JNI error has occurred, please check your installation and 
>> try again Exception in thread "main" java.lang.SecurityException: 
>> Invalid signature file digest for Manifest main attributes
>> 
>> The only suggestions I found online applied when people repackaged jars, 
>> which is not my case.
>> Any suggestion?
>> 
>> Thanks
>> 
>> Rb
> 
> 
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
> 

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: XmlSlurper, attributes and namespaces

[Winnebeck, Jason]

Ok I created https://issues.apache.org/jira/browse/GROOVY-7781

One workaround I wanted to try but never could find -- I see no way in 
GPathResult to iterate over the attributes or list the attributes. Since my 
document is entirely within a single namespace I was hoping that I could search 
for the attributes by their name, excluding the database. But when I use find 
method in GPathResult it appears to only return elements and text content and 
not attributes.

Jason

-Original Message-
From: Paul King [mailto:pa...@asert.com.au] 
Sent: Sunday, March 06, 2016 6:20 AM
To: users@groovy.apache.org
Subject: Re: XmlSlurper, attributes and namespaces

Yes, I think it is a bug. I thought we had a workaround using star, i.e. 
node.@'*:attributeName', much like node.'*:tagName' but the attribute version 
with star doesn't work either.


On Sat, Mar 5, 2016 at 7:43 PM, Pascal Schumacher  
wrote:
> Hi Jason,
>
> I do not know. It would be nice if you would create a jira issue for this.
>
> Thanks,
> Pascal
>
>
> Am 01.03.2016 um 21:21 schrieb Winnebeck, Jason:
>>
>> I can at least give the technical reason why this doesn't work -- 
>> there is namespaceMap and namespaceTagHints in GPathResult. 
>> namespaceMap is updated by declareNamespace but namespaceTagHints is 
>> not. I don't see a way to update namespaceTagHints and namespaceMap 
>> doesn't really even seem to be used. This seems like a bug in GPathResult?
>>
>> Jason
>>
>> -Original Message-
>> From: Winnebeck, Jason [mailto:jason.winneb...@windstream.com]
>> Sent: Tuesday, March 01, 2016 3:03 PM
>> To: users@groovy.apache.org
>> Subject: XmlSlurper, attributes and namespaces
>>
>> I've been struggling for a long time with XmlSlurper in how I can 
>> read attributes. Unfortunately, I have an XML document with 
>> namespaces. I wish I could ignore the namespaces, but while 
>> XmlSlurper no-arg constructor says it ignores namespaces, it does 
>> not. When using two-arg constructor to set namespaceAware to false it just 
>> asks like namespaced elements are deleted.
>> So I'm trying to figure out how to specify namespaces:
>>
>> import groovy.xml.*
>>
>> def text = """
>>c
>> """
>>
>> def xml =
>>  new XmlSlurper()
>>  .parseText(text)
>>  .declareNamespace(x:'blah')
>> //.declareNamespace(t:'blah')
>>
>> println xml.child.text() //"c" always
>> println xml.'x:child'.text() //"c" when declareNamespace x println
>> xml.'t:child'.text() //"c" when declareNamespace t
>> println xml.child.'@x:id'//"1" always
>> println xml.child.'@t:id'//"" always
>>
>> It appears that specifying namespace is optional on elements and also 
>> declareNamespace affects how I find the elements when they do have 
>> namespaces. For attributes, declareNamespace appears to have no 
>> effect, and I need to specify the prefix as it is specified in the 
>> file itself. The problem is that the generator gets to specify any 
>> prefix they want. How can I get the "id" attribute on the "child" 
>> element regardless of the namespace prefix used? (A solution dropping 
>> all namespaces is fine as there is only one namespace and no collisions).
>>
>> Thanks,
>> Jason Winnebeck
>>
>> -
>> - This email message and any attachments are for the sole use of the 
>> intended recipient(s). Any unauthorized review, use, disclosure or 
>> distribution is prohibited. If you are not the intended recipient, 
>> please contact the sender by reply email and destroy all copies of 
>> the original message and any attachments.
>
>

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy Hash Calculations

[Winnebeck, Jason]

Only the “short” solution I wrote involved buffering to memory. The “long” 
solution I wrote involves no buffering. The DigestInputStream is not related to 
whether or not there is buffering, all it does is it lets you read the stream 
and get a digest at the same time. If you are just throwing out the data, 
there’s no need for the DigestInputStream. DigestInputStream just takes the 
result of every read call and sends the bytes to MessageDigest#update before 
returning the data. DigestInputStream makes sense if you were, for example, 
passing that input stream to another method that wrote the content to a file 
then you wanted to get the digest after the file write was complete.

Jason

From: Gerald Wiltse [mailto:jerrywil...@gmail.com]
Sent: Friday, March 04, 2016 10:08 AM
To: users@groovy.apache.org
Subject: Re: Groovy Hash Calculations

I'm trying to verify the sha1 hash on a file download without saving it to 
disk, and without buffering the whole thing.  I think this solution might 
buffer all the data into "content" before going into the eachByte loop. I 
thought that was the reason for the DigestInputStream.  Do you know if this is 
correct?

Gerald R. Wiltse
jerrywil...@gmail.com<mailto:jerrywil...@gmail.com>


On Fri, Mar 4, 2016 at 9:40 AM, Winnebeck, Jason 
mailto:jason.winneb...@windstream.com>> wrote:
Here is how I would do it. I provide both a “short” solution and a “long” one. 
I would use the “short” solution if I was making for example a developer only 
tool and I knew I was only hashing small things for example a configuration 
file in a build script and want a one-liner. Otherwise I’d use the “long” 
version.

//If the content is guaranteed to be short:
def content = new ByteArrayInputStream("Here be dragons".bytes)
println MessageDigest.getInstance("SHA1").digest(content.bytes).encodeHex()

//If the content might be arbitrarily long:
content = new ByteArrayInputStream("Here be dragons".bytes)
def digest = MessageDigest.getInstance("SHA1")
content.eachByte(4096) { bytes, len ->
  digest.update(bytes, 0, len)
}
println digest.digest().encodeHex()

Jason

From: Gerald Wiltse [mailto:jerrywil...@gmail.com<mailto:jerrywil...@gmail.com>]
Sent: Friday, March 04, 2016 9:18 AM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>
Subject: Groovy Hash Calculations

Hello All,

I have this block, it's pretty compressed, just wondering if there is a more 
groovy way to handle reading the buffer and computing the hash.

def messageDigest = MessageDigest.getInstance("SHA1")
def dis = new DigestInputStream(content, messageDigest)
byte[] buffer = new byte[1024];
while (dis.read(buffer) != -1) {}
def sha1Hex = new BigInteger(1, 
messageDigest.digest()).toString(16).padLeft(40, '0')


Gerald R. Wiltse
jerrywil...@gmail.com<mailto:jerrywil...@gmail.com>


This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy Hash Calculations

[Winnebeck, Jason]

Here is how I would do it. I provide both a “short” solution and a “long” one. 
I would use the “short” solution if I was making for example a developer only 
tool and I knew I was only hashing small things for example a configuration 
file in a build script and want a one-liner. Otherwise I’d use the “long” 
version.

//If the content is guaranteed to be short:
def content = new ByteArrayInputStream("Here be dragons".bytes)
println MessageDigest.getInstance("SHA1").digest(content.bytes).encodeHex()

//If the content might be arbitrarily long:
content = new ByteArrayInputStream("Here be dragons".bytes)
def digest = MessageDigest.getInstance("SHA1")
content.eachByte(4096) { bytes, len ->
  digest.update(bytes, 0, len)
}
println digest.digest().encodeHex()

Jason

From: Gerald Wiltse [mailto:jerrywil...@gmail.com]
Sent: Friday, March 04, 2016 9:18 AM
To: users@groovy.apache.org
Subject: Groovy Hash Calculations

Hello All,

I have this block, it's pretty compressed, just wondering if there is a more 
groovy way to handle reading the buffer and computing the hash.

def messageDigest = MessageDigest.getInstance("SHA1")
def dis = new DigestInputStream(content, messageDigest)
byte[] buffer = new byte[1024];
while (dis.read(buffer) != -1) {}
def sha1Hex = new BigInteger(1, 
messageDigest.digest()).toString(16).padLeft(40, '0')


Gerald R. Wiltse
jerrywil...@gmail.com


--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: XmlSlurper, attributes and namespaces

[Winnebeck, Jason]

I can at least give the technical reason why this doesn't work -- there is 
namespaceMap and namespaceTagHints in GPathResult. namespaceMap is updated by 
declareNamespace but namespaceTagHints is not. I don't see a way to update 
namespaceTagHints and namespaceMap doesn't really even seem to be used. This 
seems like a bug in GPathResult?

Jason

-Original Message-
From: Winnebeck, Jason [mailto:jason.winneb...@windstream.com] 
Sent: Tuesday, March 01, 2016 3:03 PM
To: users@groovy.apache.org
Subject: XmlSlurper, attributes and namespaces

I've been struggling for a long time with XmlSlurper in how I can read 
attributes. Unfortunately, I have an XML document with namespaces. I wish I 
could ignore the namespaces, but while XmlSlurper no-arg constructor says it 
ignores namespaces, it does not. When using two-arg constructor to set 
namespaceAware to false it just asks like namespaced elements are deleted. So 
I'm trying to figure out how to specify namespaces:

import groovy.xml.*

def text = """
  c
"""

def xml =
new XmlSlurper() 
.parseText(text)
.declareNamespace(x:'blah')
//.declareNamespace(t:'blah')

println xml.child.text() //"c" always
println xml.'x:child'.text() //"c" when declareNamespace x println 
xml.'t:child'.text() //"c" when declareNamespace t
println xml.child.'@x:id'//"1" always
println xml.child.'@t:id'//"" always

It appears that specifying namespace is optional on elements and also 
declareNamespace affects how I find the elements when they do have namespaces. 
For attributes, declareNamespace appears to have no effect, and I need to 
specify the prefix as it is specified in the file itself. The problem is that 
the generator gets to specify any prefix they want. How can I get the "id" 
attribute on the "child" element regardless of the namespace prefix used? (A 
solution dropping all namespaces is fine as there is only one namespace and no 
collisions).

Thanks,
Jason Winnebeck

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

XmlSlurper, attributes and namespaces

[Winnebeck, Jason]

I've been struggling for a long time with XmlSlurper in how I can read 
attributes. Unfortunately, I have an XML document with namespaces. I wish I 
could ignore the namespaces, but while XmlSlurper no-arg constructor says it 
ignores namespaces, it does not. When using two-arg constructor to set 
namespaceAware to false it just asks like namespaced elements are deleted. So 
I'm trying to figure out how to specify namespaces:

import groovy.xml.*

def text = """
  c
"""

def xml =
new XmlSlurper() 
.parseText(text)
.declareNamespace(x:'blah')
//.declareNamespace(t:'blah')

println xml.child.text() //"c" always
println xml.'x:child'.text() //"c" when declareNamespace x
println xml.'t:child'.text() //"c" when declareNamespace t
println xml.child.'@x:id'//"1" always
println xml.child.'@t:id'//"" always

It appears that specifying namespace is optional on elements and also 
declareNamespace affects how I find the elements when they do have namespaces. 
For attributes, declareNamespace appears to have no effect, and I need to 
specify the prefix as it is specified in the file itself. The problem is that 
the generator gets to specify any prefix they want. How can I get the "id" 
attribute on the "child" element regardless of the namespace prefix used? (A 
solution dropping all namespaces is fine as there is only one namespace and no 
collisions).

Thanks,
Jason Winnebeck

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Optional parentheses for methods with all uppercase names

[Winnebeck, Jason]

I didn't see this explanation in the linked thread, but from what I've heard in 
situations where a symbol can be interpreted as a function or a Class, the rule 
that is used to choose between the cases is the initial uppercase letter. So 
"Foo" is the name of a class but "foo" is the name of a local symbol or 
function. That makes "String x" a variable declaration but "string x" a call to 
"string(x)".

Jason

-Original Message-
From: OC [mailto:o...@ocs.cz] 
Sent: Sunday, February 28, 2016 11:49 AM
To: users@groovy.apache.org
Subject: Re: Optional parentheses for methods with all uppercase names

We have bumped into this parser issue long long ago, see

http://www.groovy-lang.org/mailing-lists.html#nabble-td5722268

All the best,
OC

On 27. 2. 2016, at 23:19, Bay Batu  wrote:

> Hello,
> 
> I tried it and it looks like an issue about first letter's case. 
> 
> For example,
> 
> *
> def Foo(a){
>   print a
> }
> 
> Foo "berbat"
> *
> gives compilation error: unexpected token berbat
> 
> But it does not give a compilation error when i change it like that.
> 
> *
> def fOo(a){
>   print a
> }
> 
> fOo "berbat"
> *
> 
> /baybatu
> 
> 
> 
> 
> 
> 
>> On Feb 28, 2016, at 00:08, matthias.grue...@gmail.com wrote:
>> 
>> [First off I apologize for possibly reposting this question. My original 
>> posting never went out to the maillist due to unknown reasons. This is my 
>> second attempt. Sorry if you already read this before.]
>> 
>> I am a developing a Groovy DSL to create Dockerfiles
>> 
>> The format of a Dockerfile looks like:
>> 
>> INSTRUCTION arguments
>> 
>> Instructions are case-insensitive but convention is for them to be UPPERCASE.
>> 
>> However Groovy doesn't seem to support optional parentheses if the method 
>> name is all uppercase:
>> 
>> def FOOBAR(String msg) {
>> println msg
>> }
>> FOOBAR "hello"
>> 
>> groovyc: unexpected token: hello @ line 2, column 8.
>> FOOBAR "hello"
>> ^
>> 
>> Do you know of any way to get this to work or is this a known limitation of 
>> Groovy?
>> 
>> I tried with Groovy version 2.4.5
>> 
>> If anyone has any insight, it would be very helpful.
>> 
>> /matthias 
>> 
>> -- 
>> Matthias Grüter
>> www.grueter.name   //   matth...@grueter.name
> 

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovysh in non-interactive mode

[Winnebeck, Jason]

Is groovy -e a solution to this problem?

Jason

-Original Message-
From: Thibault Kruse [mailto:tibokr...@googlemail.com] 
Sent: Friday, February 05, 2016 8:57 AM
To: users@groovy.apache.org
Subject: Re: Groovysh in non-interactive mode

Yes, the JIRA ticket you mentioned is responsible for that (so blame me for the 
change). I don't have much time to discuss this now, next week will be better. 
You might comment on your case in the JIRA ticket. It should not be hard to add 
back a non-interactive mode to the interactive shell, even if that sounds 
strange.

On Fri, Feb 5, 2016 at 3:13 AM, cyprushelp  wrote:
> Hello,
>
> Groovysh no longer works in non-interactive mode.
>
> 1) Before Groovy 2.4, you could run groovysh in non-interactive mode. 
> It would execute the action and then quit. This made it useful when 
> embedding in shell scripts etc.
> 2) Before Groovy 2.4, you could pass arguments to groovysh in 
> non-interactive mode. For example, I had some custom commands which I 
> could execute not only from within the shell, but also outside of the shell.
>
> Both these features seem to be gone in latest Groovy 2.4.5 release. 
> They were useful and a lot of code depended on them. I wonder if 
> someone has any workarounds. I am not sure if the changes in
> https://issues.apache.org/jira/browse/GROOVY-6754 caused this.
>
> Before (groovy 2.3.9):
> user@machine:~$ groovysh :show all
> No variables defined
> No classes have been loaded
> No custom imports have been defined
> Preferences:
> verbose=false
> ===> [null, null, null, null]
> user@machine:~$
>
> After (groovy 2.4.5):
> user@machine:~/opt/groovy-2.4.5/bin$ ./groovysh :show all Groovy Shell 
> (2.4.5, JVM: 1.8.0_51) Type ':help' or ':h' for help.
> --
> --
> 
> groovy:000> :load :show
> File not found: ":show"
> groovy:000> :load all
> File not found: "all"
> groovy:000>

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: GGTS

[Winnebeck, Jason]

As unfortunate as it is, it could be documented on Groovy site that users 
should either use IntelliJ or older Eclipse where the plugin works. That would 
solve at least the initial impression of Groovy. It can be noted that even the 
free version of IntelliJ works with Groovy.

Jason

-Original Message-
From: Guillaume Laforge [mailto:glafo...@gmail.com] 
Sent: Friday, January 22, 2016 11:19 AM
To: users@groovy.apache.org
Subject: Re: GGTS

Agreed with your analysis Jochen.

On Fri, Jan 22, 2016 at 5:09 PM, Jochen Theodorou  wrote:
>
>
> On 22.01.2016 11:34, Guillaume Laforge wrote:
>>
>> Hi Michael,
>>
>> As Pivotal stopped the development & maintenance of GGTS, you won't 
>> see a new version anytime soon, unfortunately.
>> I'm not 100% sure what's the state of the Eclipse plugin though, 
>> perhaps the situation is better there (I'm using IntelliJ IDEA 
>> myself, so I can't comment) That said, the developers of GGTS (and 
>> actually of the Eclipse plugin
>> too) are willing to help someone who'd want to ramp up and contribute 
>> to the development, in case you'd be interested in helping!
>
>
> It is actually quite sad... I mean we are kind of loosing all those 
> developers that are forced to use Eclipse.. ahem... and those that 
> simply prefer Eclipse of Idea. It is an entry barrier... they try the 
> plugin out, maybe it is then not working any more, because nobody 
> helped keeping it up-to-date with Eclipse and then they think Groovy is 
> stupid and unusable...
> end of story.
>
> But given the current situation I don't know anyone having spare 
> cycles to spend on the eclipse plugin. There have been some people in 
> the past saying they may help the eclipse plugin, but if they will 
> actually do something is yet to be seen I think. So there is interest, 
> but time is missing... and eclipse/JDt is not something you can get into on a 
> weekend.
>
> So even though I am not using Eclipse anymore myself, I would be quite 
> happy in seeing the groovy eclipse plugin to continue living. I mean 
> it is in a pretty good shape right now... but it needs people keeping 
> it in sync with eclipse, even if they fix not a single bug.
>
> bye Jochen



--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet

Blog: http://glaforge.appspot.com/
Social: @glaforge / Google+

--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: A @CompileStatic for class members

[Winnebeck, Jason]

What surprises me is that accessing by property is a lot slower than setter. I 
suppose I figured once Groovy fully initialized the MOP and call site that 
t.member = 1 would perform essentially exactly the same as t.setMember(1).

However, this test might have the normal micro-benchmark faults, since the 
side-effects are not used, we can’t really predict what the JIT might do (such 
as eliminating some instructions entirely), or triggering a method optimization 
on the script’s run method after the first for loop but before the second (I 
don’t remember precisely how JIT works when you are not re-entering the method 
continuously, but I don’t think every instruction is a possible point where it 
can jump to the JIT-ed version). I wonder if using a tool like JMH would change 
the results.

Jason

From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Thursday, January 21, 2016 10:52 AM
To: users@groovy.apache.org
Subject: Re: A @CompileStatic for class members

Your benchmark is wrong, because the caller is not statically compiled. What 
you have statically compiled is the `Test` class, but the caller is not. So 
when you do `t.setMember(..)`, the call is dynamic. It's the caller that you 
have to statically compile (or both, ideally).

2016-01-21 16:39 GMT+01:00 Marshall, Simon 
mailto:simon.marsh...@misys.com>>:
Hi all, I’d like class field access in specific classes to be without groovy 
magic, so that it is as fast as possible.  I guess this means disabling runtime 
metaprogramming for specific classes (or fields).

At first, the 
http://docs.groovy-lang.org/latest/html/api/groovy/transform/CompileStatic.html 
annotation looked like it might do the trick, as it mentions class properties 
being covered.  It certainly works for class methods, but in my testing it 
didn’t make any difference to class members.  Setting the field “directly” (ie, 
via t.member below) is still an order of magnitude slower than using its 
implicit setter directly (ie, t.setMember()).  Similarly for field access vs 
getter.  That annotation does not seem to cover field access or assignment.

So, is there a way to make field access as quick as using the implicit 
getter/setter?  Thanks, Simon.

For example, on my 3+GHz Xeon with jdk1.8.0_66/groovy-all-2.4.3, the below code 
gives me:

t.member = val  34.577
t.setMember(val)3.529
t.with { member = val } 127.922

package test

import groovy.transform.CompileStatic

@CompileStatic
class Test {
String member
}

String val = 'test'
Test t = new Test()

for (long i = 0; i < 100 * 1000 * 1000; ++i) {
t.setMember(val)
}

long time = 1000 * 1000 * 1000
long beg = System.currentTimeMillis()
for (long i = 0; i < time; ++i) {
t.member = val
}
println('t.member = val\t\t'+(System.currentTimeMillis() - beg) / 1000.0)

beg = System.currentTimeMillis()
for (long i = 0; i < time; ++i) {
t.setMember(val)
}
println('t.setMember(val)\t'+(System.currentTimeMillis() - beg) / 1000.0)

beg = System.currentTimeMillis()
for (long i = 0; i < time; ++i) {
t.with { member = val }
}
println('t.with { member = val }\t'+(System.currentTimeMillis() - beg) / 1000.0)

"Misys" is the trade name of the Misys group of companies. This email and any 
attachments have been scanned for known viruses using multiple scanners. This 
email message is intended for the named recipient only. It may be privileged 
and/or confidential. If you are not the named recipient of this email please 
notify us immediately and do not copy it or use it for any purpose, nor 
disclose its contents to any other person. This email does not constitute the 
commencement of legal relations between you and Misys. Please refer to the 
executed contract between you and the relevant member of the Misys group for 
the identity of the contracting party with which you are dealing.


--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

RE: Groovy Beta

[Winnebeck, Jason]

Sorry, I wasn't clear. By snapshot I meant a declaration/tag by the developers. 
For example when Groovy team releases 2.5.0-beta1, not only is it something I 
can explain globally "we are using 2.5.0-beta1 and see xyz", but it also means 
that the team is saying the code is in a reasonable state for someone to use 
(i.e. there's not a major refactor in progress -- for example I have no clue if 
2.5.0 being a new feature branch has a refactor going on).

Anyway, knowing about the snapshot builds is useful as I can eliminate any 
potential mistake in my build process. I will try that snapshot JAR Monday to 
verify the fix for GROOVY-7705 for our application.

I apologize about the side-tracked conversation, initially I only meant to ask 
whether or not a release was soon to know if I should go through the effort of 
validating a nightly for a production system. Since 2.5 beta is not soon, the 
only open question left for me is if GROOVY-7705 could be backported into 2.4.6 
or at least 2.4.x (I'd feel safer with a 2.4.7-SNAPSHOT than 2.5.0-SNAPSHOT). I 
asked that in the JIRA.

-Original Message-
From: Pascal Schumacher [mailto:pascalschumac...@gmx.net] 
Sent: Friday, January 15, 2016 2:54 PM
To: users@groovy.apache.org
Subject: Re: Groovy Beta

Hi Jason,

you do not have to build it yourself if you want to validate a snapshot.

You can add https://oss.jfrog.org/artifactory/oss-snapshot-local/ as a maven 
repo and pull 2.5.0-SNAPSHOT from there.

-Pascal

Am 15.01.2016 um 20:46 schrieb Winnebeck, Jason:
> I have built Groovy on my home machine successfully, it is not bad at all. 
> However, I'm working on a large enterprise app, so it is nice to at least 
> have some form of snapshot in time. So, I can deploy it to our local Maven 
> repository under different group ID, but then I still have the uncertainty of 
> pulling the latest code and not even knowing if there is a half-finished task 
> or refactor going on in there, whereas with a "blessed" beta the team is 
> saying they think the code is clean. I could validate the "tip" works in our 
> app but that is not productive if a release is coming soon. There's also the 
> awkward-ness of having a custom-built Groovy not-quite-2.4 but not-quite-2.5 
> version out and about. However, the fix is big enough for me that if it 
> doesn't make it into the recent 2.4.6 release, I may very well go through the 
> effort to build the tip of beta branch and validate.
>
> Jason
>
> -Original Message-
> From: Russel Winder [mailto:rus...@winder.org.uk]
> Sent: Friday, January 15, 2016 2:29 PM
> To: users@groovy.apache.org
> Subject: Re: Groovy Beta
>
> On Fri, 2016-01-15 at 19:05 +, Winnebeck, Jason wrote:
>> A Groovy issue that affects us significantly was recently fixed in 
>> the Apache JIRA as "2.5.0-beta1". From what I can tell, there is not 
>> currently a place to download betas. Is there a plan to release a 
>> Groovy 2.5 beta milestoon soon?
> Probably not. I compile and install from source. Takes about 22 mins on my 
> workstation (which is 9 years old so I expect modern kit to do better).
>
> --
> Russel.
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> --
> This email message and any attachments are for the sole use of the intended 
> recipient(s). Any unauthorized review, use, disclosure or distribution is 
> prohibited. If you are not the intended recipient, please contact the sender 
> by reply email and destroy all copies of the original message and any 
> attachments.

RE: Groovy Beta

[Winnebeck, Jason]

I have built Groovy on my home machine successfully, it is not bad at all. 
However, I'm working on a large enterprise app, so it is nice to at least have 
some form of snapshot in time. So, I can deploy it to our local Maven 
repository under different group ID, but then I still have the uncertainty of 
pulling the latest code and not even knowing if there is a half-finished task 
or refactor going on in there, whereas with a "blessed" beta the team is saying 
they think the code is clean. I could validate the "tip" works in our app but 
that is not productive if a release is coming soon. There's also the 
awkward-ness of having a custom-built Groovy not-quite-2.4 but not-quite-2.5 
version out and about. However, the fix is big enough for me that if it doesn't 
make it into the recent 2.4.6 release, I may very well go through the effort to 
build the tip of beta branch and validate.

Jason

-Original Message-
From: Russel Winder [mailto:rus...@winder.org.uk] 
Sent: Friday, January 15, 2016 2:29 PM
To: users@groovy.apache.org
Subject: Re: Groovy Beta

On Fri, 2016-01-15 at 19:05 +, Winnebeck, Jason wrote:
> A Groovy issue that affects us significantly was recently fixed in the 
> Apache JIRA as "2.5.0-beta1". From what I can tell, there is not 
> currently a place to download betas. Is there a plan to release a 
> Groovy 2.5 beta milestoon soon?

Probably not. I compile and install from source. Takes about 22 mins on my 
workstation (which is 9 years old so I expect modern kit to do better).

--
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.