from:"mg"

For anyone who might have missed that: You can coveniently vote for each 
child issue from the umbrella issue 
(https://youtrack.jetbrains.com/issue/IDEA-193168) by clicking on the 
thumbs up icon right next to the child issue's name G-)


Cheers,
mg


 Forwarded Message 
Subject: 	[YouTrack, Voted] Issue IDEA-193168: Fully Support Groovy 2.5 
Features

Date:   Thu, 12 Mar 2020 20:55:58 +
From:   Mikhail Stepura 
To: M G 



Feature was updated by Mikhail Stepura in project IntelliJ IDEA at 12 
Mar 2020 23:53.
	IDEA-193168 
<https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FIDEA-193168> 
Fully Support Groovy 2.5 Features 
<https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FIDEA-193168> 
Created by you


Votes   +1 (Mikhail Stepura). Total votes: 44

This message was sent by YouTrack <https://jetbrains.com/youtrack>, an 
issue tracker by JetBrains. You (*nahgeh*) received this message because 
you subscribe to notification events for the *Reported by me* saved 
search. To unsubscribe, you can mute notifications for this issue 
<https://youtrack.jetbrains.com/api/unsubscribe?token=MTU4NjU2MzIwMDAwMHwxMS0zNzMzMDV8MjUtMjAwOTc5OHxqZ0NLeWpONmVhalQ5b3MyUGhyZC04%0D%0ASHUxUWlZa1pDY2p5YlR1b1pkbzI0DQo%0D%0A> 
or edit your notification preferences 
<https://youtrack.jetbrains.com/oauth?state=%2Fusers%2F0d5f7108-2302-45ea-b002-9b0e7fb93f58%3Ftab%3Dnotifications>. 
[search: Reported by me] YouTrack 2019.3.67768

IntelliJ IDEA Groovy 2.5/3.0 Feature Support - @NamedVariant - Plz vote


@NamedVariant issue is up: https://youtrack.jetbrains.com/issue/IDEA-235133

As always please vote,
Cheers,
mg

*Right now we have 9 and 8 votes for the existing individual child 
issues - thank to everyone who took the time - but we have 43 votes for 
the umbrella task...

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

@IntelliJ's build system: We use IntelliJ Groovy build, and have very 
vanilla requirements with regards to building our projects (basically 
it's just a larger number of interdependent modules with a bunch of 
artifacts), but alas even that does not work without a hitch: The 
"build-repeatedly-magically-fails"-problem I described here a while ago 
has (after years) thankfully disappeared, just to be replaced by a more 
benign one, where any change in one of a couple of our central Groovy 
modules makes the regular minimal rebuild fail, and we always have to 
rebuild the failing module in its entirety in that case. We can only 
live with it since those modules are relatively stable.*


Also Intellisense in the IntelliJ version we are currently using 
(2019.3.1) gets confused after a short while, and will mark correct code 
as invalid (as a weird workaround, one can comment out the "invalid" 
part of the line, and when commenting it back in, IntelliJ will be back 
on track most of the time).*


Which brings me to:
@"Another thing that comes to mind, JetBrains produces Kotlin, and 
Kotlin competes with Groovy - figure that one out!"
Alas, yes. As I have said here back when the discussion about Gradle 
Groovy vs Kotlin happened, there is an obvious conflict of interests 
here  - ideally you would want your IDE supplier to be as language 
agnostic as possible, which, due to the introduction of and ongoing 
investment in Kotlin, for Jetbrains is no longer the case.
I am still giving them the benefit of the doubt, but thinking back, 
IntelliJ Groovy support used to be top notch, and nowadays it is 
incomplete and suffers from quite a bit of problems. Hmmm...


In any case, even though the Groovy ecosystem is large & strong, in the 
end we are small fry, since it seems obvious to me their actual goal is 
not to replace Groovy, but over time to replace Java.
Then the #1 IDE and the #1 JVM language would come from one company in 
Prague. Not my dream scenario, for sure, after Java and the JVM 
landscape finally made big strides to being completely open source & 
much more community driven... (if I wanted MS (i.e. Visual Studio** & 
C#), I would not have returned to the JVM world from .NET in 2008)


Cheers,
mg

*None of that can be fixed by clearing the IntelliJ caches btw, we do 
that on a regular basis.
**Ironically enough, ReSharper by Jetbrains, at least back then, used to 
be the quintessential Visual Studio refactoring plugin back in 2008.




On 11/03/2020 19:36, Blake McBride wrote:

Hi MG,

The issues I've had with IntelliJ/JetBrains are general. IntelliJ is 
probably the best IDE out there but rather than make it even better 
they seem comfortable just staying a notch above the competition.  I 
guess they don't have to do better.


I've had issues with IntelliJ that are utterly and clearly wrong but 
they say it is a "feature".


Other times I spend hours trying to get IntelliJ to do something that 
ends up hidden deep in the bowels of IntelliJ rather than putting them 
where someone would look for them. This causes hours of wasted time, 
immense frustration, and needless contact with their support.


While their support is very responsive, they're too quick to 
dismiss nearly every issue.


Often a clear bug is discovered but their attitude is that not enough 
people use that feature so we're not going to fix it.  This attitude 
has been a big problem and might also be a factor in the Groovy issue.


Another thing that comes to mind, JetBrains produces Kotlin, and 
Kotlin competes with Groovy - figure that one out!


I've always thought that NetBeans was the most intuitive IDE.  Anytime 
I want to do something I guess at where it is and - boom - there it 
is!  I also see they're really making an effort to upgrade it.  I'll 
be watching them.


IntelliJ, like most build systems, has a convention over configuration 
attitude.  While this works really really well when you are building a 
conventional app, with either, when you try to drift the 
slightest from the convention (with good reason!) a five-minute setup 
can turn into weeks and constant headaches!!  In order to get around 
IntelliJ's and other build system's (Maven, Gradle, etc.) conventions, 
I ended up writing my own build system.  Problem is, I still need an 
IDE for developing and debugging.  I try not to use them for builds.


With regard to eclipse, personally, I've never worked with a worse IDE 
than eclipse.  eclipse:


1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used

I've had a lot better luck with NetBeans!

A number of years ago I embarked, with a team, on a large Java 
project.  We started with eclipse.  We had endless memory issues and 
crashes.  We then switched to NetBeans

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues


Hi Blake,

thanks for sharing your experience, I am also not the biggest Eclipse 
fan, though I found it not too bad as a Java IDE a while back.


It is funny that you should mention Netbeans - I had nearly forgotten 
about it*, but I actually had the same as experience as you did with 
Netbeans: It was very intuitive, besides Java (and C++) had great 
Javascript support out of the box (whereas Eclipse sucked at this, 
whatever plugin I tried), and in general the fact that it did not put 
you in plugin hell and was not based on a "generic editor for 
everything" base appealed to me. Alas Groovy support was severly 
outdated/lacking a few years back when I evaluated our IDE options - 
does anyone have any recent experiences on what the status of Netbeans 
is with regards to Groovy support ?


Cheers,
mg

*Partially because other (Java only) teams in my organization are using 
Eclipse, and it is always like "Why do you guys need IntelliJ then ?" - 
to which the answer of course used to be "Because it has unparalleled 
Groovy support"



On 11/03/2020 19:36, Blake McBride wrote:

Hi MG,

The issues I've had with IntelliJ/JetBrains are general. IntelliJ is 
probably the best IDE out there but rather than make it even better 
they seem comfortable just staying a notch above the competition.  I 
guess they don't have to do better.


I've had issues with IntelliJ that are utterly and clearly wrong but 
they say it is a "feature".


Other times I spend hours trying to get IntelliJ to do something that 
ends up hidden deep in the bowels of IntelliJ rather than putting them 
where someone would look for them. This causes hours of wasted time, 
immense frustration, and needless contact with their support.


While their support is very responsive, they're too quick to 
dismiss nearly every issue.


Often a clear bug is discovered but their attitude is that not enough 
people use that feature so we're not going to fix it.  This attitude 
has been a big problem and might also be a factor in the Groovy issue.


Another thing that comes to mind, JetBrains produces Kotlin, and 
Kotlin competes with Groovy - figure that one out!


I've always thought that NetBeans was the most intuitive IDE.  Anytime 
I want to do something I guess at where it is and - boom - there it 
is!  I also see they're really making an effort to upgrade it.  I'll 
be watching them.


IntelliJ, like most build systems, has a convention over configuration 
attitude.  While this works really really well when you are building a 
conventional app, with either, when you try to drift the 
slightest from the convention (with good reason!) a five-minute setup 
can turn into weeks and constant headaches!!  In order to get around 
IntelliJ's and other build system's (Maven, Gradle, etc.) conventions, 
I ended up writing my own build system.  Problem is, I still need an 
IDE for developing and debugging.  I try not to use them for builds.


With regard to eclipse, personally, I've never worked with a worse IDE 
than eclipse.  eclipse:


1. the most unintuitive IDE I've ever used
2. the most buggy IDE I've ever used
3. the most out-of-date IDE I've ever used
4. the least supported IDE I've ever used

I've had a lot better luck with NetBeans!

A number of years ago I embarked, with a team, on a large Java 
project.  We started with eclipse.  We had endless memory issues and 
crashes.  We then switched to NetBeans and used it without 
incident for years.  I eventually switched to IntelliJ because of a 
promised feature.  I spent a lot of time moving this project (10,000 
classes!) to IntelliJ only to find that the promised feature is 
extremely buggy.  When I reported the problems JetBrains told me that 
not enough people used the feature and they are no longer supporting it.


While IntelliJ's support of Kotlin will no doubt remain first-class, 
my inclination is that Groovy will experience declining support by 
JetBrains for the above reasons.  Moving forward, you may have better 
luck with NetBeans.


[rant over]

Thanks.

Blake

On Wed, Mar 11, 2020 at 12:33 PM MG <mailto:mg...@arscreat.com>> wrote:


Hi Blake,

first of all thank you, and all who voted since my post, for
taking the time, appreciated.

Second: Is your IntelliJ/Jetbrains experience directly tied to
Groovy or to issues in general ? The guy responsible for Groovy in
IntelliJ, Daniil Ovchinnikov, seems to need community created,
upvoted child tasks:
see for instance his comment on the "Support for Groovy 3 syntax"
issue on  5 Dec 2018 17:07:
"@Pradeep Bhardwaj don't worry, the work is in progress. Most of
Groovy 3 features are already supported, please see child tasks
and vote for some (or all) of them."

In any case upvoting is the only thing we can easily do. If this
has no effec

IntelliJ IDEA Groovy 2.5/3.0 Feature Support - @MapConstructor

2020-03-11 Thread MG

I have checked @AutoImplement, and that seems to be working; existing 
closed issue has just been linked to umbrella task by Daniil.


Please vote for the @MapConstructor issue I just created: 
https://youtrack.jetbrains.com/issue/IDEA-235059


Cheers,
mg

Re: IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

2020-03-11 Thread MG


Hi Blake,

first of all thank you, and all who voted since my post, for taking the 
time, appreciated.


Second: Is your IntelliJ/Jetbrains experience directly tied to Groovy or 
to issues in general ? The guy responsible for Groovy in IntelliJ, 
Daniil Ovchinnikov, seems to need community created, upvoted child tasks:
see for instance his comment on the "Support for Groovy 3 syntax" issue 
on  5 Dec 2018 17:07:
"@Pradeep Bhardwaj don't worry, the work is in progress. Most of Groovy 
3 features are already supported, please see child tasks and vote for 
some (or all) of them."


In any case upvoting is the only thing we can easily do. If this has no 
effect, my team will have to look into the Eclipse option again - great, 
after we convinced management that paying for IntelliJ was the way to go :-/

mg


On 11/03/2020 17:50, Blake McBride wrote:
Although I will vote up the Groovy issue you detail, being a long-time 
IntelliJ user, I can tell you first hand that upvoting an issue at 
JetBrains has no effect I am aware of.  I have seen critical issues 
get hundreds of votes and remain untouched for years.  They do what, 
when, and how they like.


On Wed, Mar 11, 2020 at 11:27 AM MG <mailto:mg...@arscreat.com>> wrote:


Hi guys,

up to this point, the first issue I created two days ago (see
previous
post for link) has gotten zero votes - if no one is voting for these
issues, then it makes no sense for me to put them up, so please do
not
only vote for the umbrella issue (which just got vote 37 - still
incredibly low given the large number of Groovy users out there), but
for each individual issue as well.

Consider to not only vote for the features you yourself would
immediately use - all of these features were included after some
discussion, because they were considederd to make Groovy a better
language, and some things need time to establish themselves, but
there
is no chance of that happening, if the most prevalent Groovy IDE
marks
the code as invalid and accordingly offers no
Intellisense/refactoring/etc support*.

Cheers,
mg

*I keep wondering what people new to Groovy think, if they try to
use a
feature introduced nearly 2 years ago, but their IDE marks it as
invalid
code...

IntelliJ IDEA Groovy 2.5/3.0 - Vote for Indiviudal Issues

2020-03-11 Thread MG


Hi guys,

up to this point, the first issue I created two days ago (see previous 
post for link) has gotten zero votes - if no one is voting for these 
issues, then it makes no sense for me to put them up, so please do not 
only vote for the umbrella issue (which just got vote 37 - still 
incredibly low given the large number of Groovy users out there), but 
for each individual issue as well.


Consider to not only vote for the features you yourself would 
immediately use - all of these features were included after some 
discussion, because they were considederd to make Groovy a better 
language, and some things need time to establish themselves, but there 
is no chance of that happening, if the most prevalent Groovy IDE marks 
the code as invalid and accordingly offers no 
Intellisense/refactoring/etc support*.


Cheers,
mg

*I keep wondering what people new to Groovy think, if they try to use a 
feature introduced nearly 2 years ago, but their IDE marks it as invalid 
code...

Re: IntelliJ IDEA Groovy 2.5/3.0 Feature Support - @Newify(pattern=...)

2020-03-08 Thread MG

In my personal opinion we should fade out the older solutions that do 
not support final class fields, have no type safety, etc, so I would not 
push Jetbrains to put effort into supporting this.
If one wants instance creation without new in Groovy, I expect he 
typically will put @Newify(pattern = /[A-Z].*/) into his Groovy 
configscript, to have it active in every class, so it would not matter 
that the older, more restricted version works without any annotation.


Cheers,
mg


On 09/03/2020 01:36, Paul King wrote:
The named argument shorthand, which doesn't require @Newify, displays 
errors too (currently won't work with your Foo example since it relies 
on a no-arg constructor and setters):

image.png
Cheers, Paul.

On Mon, Mar 9, 2020 at 10:00 AM MG <mailto:mg...@arscreat.com>> wrote:


Hi Groovy users,

the current IntelliJ IDEA (2019.3.3, built on February 11th 2020)
still
does not support all Groovy features introduced with Groovy 2.5.4
in mid
2018 (http://groovy-lang.org/releasenotes/groovy-2.5.html). I have
created an umbrella issue for this back then
(https://youtrack.jetbrains.com/issue/IDEA-193168), but it seems to
never have been fleshed out / worked on.

To help remedy this, I am planning to create indiviudal issues,
starting
with support for creating class instances without requiring the
use of
the new keyword:
https://youtrack.jetbrains.com/issue/IDEA-234806.

Groovy is all about being as concise and elegant as possible, so
it did
away with the needless Java semicolon at the end of lines, supports
string interpolation and multiline strings, etc. Creating class
instances / calling constructors without a new keyword is
something that
has existed in Python and Kotlin forever, so it is high time IntelliJ
IDEA supported this Groovy feature.

Please vote for these issues as I report them G-)
Cheers,
mg

IntelliJ IDEA Groovy 2.5/3.0 Feature Support - @Newify(pattern=...)

2020-03-08 Thread MG


Hi Groovy users,

the current IntelliJ IDEA (2019.3.3, built on February 11th 2020) still 
does not support all Groovy features introduced with Groovy 2.5.4 in mid 
2018 (http://groovy-lang.org/releasenotes/groovy-2.5.html). I have 
created an umbrella issue for this back then 
(https://youtrack.jetbrains.com/issue/IDEA-193168), but it seems to 
never have been fleshed out / worked on.


To help remedy this, I am planning to create indiviudal issues, starting 
with support for creating class instances without requiring the use of 
the new keyword:

https://youtrack.jetbrains.com/issue/IDEA-234806.

Groovy is all about being as concise and elegant as possible, so it did 
away with the needless Java semicolon at the end of lines, supports 
string interpolation and multiline strings, etc. Creating class 
instances / calling constructors without a new keyword is something that 
has existed in Python and Kotlin forever, so it is high time IntelliJ 
IDEA supported this Groovy feature.


Please vote for these issues as I report them G-)
Cheers,
mg

Re: please help : GroovyCastException: why ? - introduce @ClassName annotation ?

2020-02-28 Thread MG

Glad the community could help you & things look Groovy now G-)

Cheers,

mg

On 28/02/2020 09:02, Mickaël SALMON wrote:

Thank you very much for your support.
Except this tricky use case for which I'm sure  will find a solution 
for refactoring the existing scripts, Groovy integration in my Java 
application is OK Now.

Chers, Mickael.

*From:* Jochen Theodorou 
*Sent:* Thursday, February 27, 2020 16:39
*To:* Mickaël SALMON 
*Subject:* Re: please help : GroovyCastException: why ?

Am 27.02.20 um 16:16 schrieb Mickaël SALMON:
> Okay.
>
> In fact, I don't understand which this code works in Java but not in
> Groovy (even if naming a variable with a class name, not in camel case,
> is weird ...).

That is because Groovy has an overlap of variable names and class names
Java does not have.

In Java a=b is clearely assigning the value of variable b to a. If a is
a class instead it will fail compilation. If there is a variable b and b
class a, then the variable will be taken. To ensure you do mean the
class, you have to write a=b.class

In Groovy a=b is different.here b could be also a class b. if there is
no local variable b, then b might be still a class or (dynamic)
property. Thus the compiler will first check if it is a class and then
proceed to make it a (dynamic) property access. In dynamic Groovy this
expression def a=b may never fail compilation, because even if there is
no class b and no local variable b and no static property b, there is
still a possibly dynamic property b. If it then does not exist at
runtime, you will get a MissingPropertyException. But this mechanism
proofed to be problematic for the users. It turned out to be a problem
for the performance. Which is why we said, that if the name b follows
the class naming conventions of upper-case and camel-case, it must be a
class name and otherwise not.

bye Jochen

Re: please help : GroovyCastException: why ?

2020-02-24 Thread MG


Article articleTmp = (Article) Article;

in Groovy is the same as

Article articleTmp = (Article) Article.getClass();

in Java.

Article.getClass()

is of type Class, so casting it to Article will fail - what you 
want to do ist pass an Article instance, not the class, I presume...


hth,
mg


On 24/02/2020 18:24, Mickaël SALMON wrote:

Hello,

I'm using last Groovy version (3.0.1) in my Java application to run 
user defined scripts (Java based).

Here is how a script is executed (sorry for the formatting) :

   public Object eval(String scriptName, String script, MapObject> mapVariable)

                   throws CochiseException {
       groovy.lang.Script groovyScript = this.scriptCache.get(scriptName);
       if (groovyScript == null) {
           groovyScript = new GroovyShell().parse(script);
 this.scriptCache.put(scriptName, groovyScript);
       }
 groovyScript.setBinding(new Binding(mapVariable));
       return groovyScript.run();
   }

I have the following exception when I pass the object "Article" of 
class "com.sylob.cochise.dm1.ejb.entite.article.Article" in the Map of 
variables :


org.codehaus.groovy.runtime.typehandling.GroovyCastException:
Cannot cast object 'interface
com.sylob.cochise.dm1.ejb.entite.article.Article' with class
'java.lang.Class' to class
'com.sylob.cochise.dm1.ejb.entite.article.Article'


Here is the script :

import com.sylob.cochise.dm1.ejb.entite.article.Article;

println "CL import Article : " +  Article.class.getClassLoader()
println "CL var Article: " + Article.getClass().getClassLoader()

Article articleTmp = (Article) Article;
// ... some stuff


This not seem to be a classLoader problem, because same class loader 
is used to load both com.sylob.cochise.dm1.ejb.entite.article.Article 
class in the script and "Article" object in the calling application.

Also tested with 2.5.9, same error.

What's wrong here ?

Thanks.

Re: [ANNOUNCE] Apache Groovy 3.0.0 released

2020-02-10 Thread MG

G-)reat job Groovy team, congrats & much appreciated !

On 10/02/2020 14:05, Paul King 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.

Re: Ubuntu Snaps

2019-06-28 Thread MG


@scripting: G-)

@linuxbrew: Thnx for the info. What I meant was that alas neither our 
servers nor clients are connected to the internet, so all these nice 
services (including Maven repositories *sigh*) do not work...



On 28/06/2019 17:20, Tamás Cservenák wrote:

Same here re scripting...

But just FYI, groovy is available from linuxbrew as well (macOS know 
what Homebrew is, this is linux flavor that is now merged into 
official Homebrew).
Along with adoptopenjdk and groovy (and rest of tools brew offers), 
for me, it is the simplest way to keep up to date with these tools.


Thanks and happy brewing!
Tamas

On Fri, Jun 28, 2019 at 5:12 PM MG <mailto:mg...@arscreat.com>> wrote:


I'm always pushing to use Groovy instead of Unix scripting or Python,
Perl, ... fors scripting on our servers, so even if we cannot use
such
services in our environment, that is a good development :-)

Re: Ubuntu Snaps

2019-06-28 Thread MG

I'm always pushing to use Groovy instead of Unix scripting or Python, 
Perl, ... fors scripting on our servers, so even if we cannot use such 
services in our environment, that is a good development :-)


On 28/06/2019 11:14, Paul King wrote:


Hi everyone,

Linux users can now get Groovy via the Snap Store:

https://snapcraft.io/groovy

Full instructions for many common distros are available from that 
site. It will normally involve running:


> snap install groovy --classic

... once you have Snap installed (if you don't already). Or if you 
have the Snap Store graphical desktop application, you can simply 
browse to Apache Groovy and click Install.


For Linux users, Snaps complement the other ways of getting Groovy. Enjoy!

Cheers, Paul.

Re: requesting your advice on picocli modules

2019-05-31 Thread MG


Hi Remko,

I agree option 1) is the cleanest, as well as it being the direction all 
of Groovy seems to be moving.


Cheers,
mg


On 30/05/2019 14:50, Remko Popma wrote:

Hi,

I maintain the picocli library for creating command line applications 
in Groovy, Java, and other JVM languages.

I have a question for the Groovy community (both users and developers):

Currently, the picocli main jar contains both the core `picocli` 
package and a `picocli.groovy` package with classes that make it easy 
for Groovy scripts to use picocli annotations. I'm considering 
splitting up this jar.


In an upcoming major release of the library I plan to provide a Java 9 
JPMS modular jar containing just the core `picocli` package and 
additionally a `module-info.class` to make this jar a full-fledged 
Java module.


The question is what to do with the picocli.groovy package. I see two 
options:
1) have a `picocli-groovy` jar containing _only_ the picocli.groovy 
package - this jar would require (have a dependency on) the core 
picocli jar (the JPMS modular jar). Ideally this `picocli-groovy` jar 
would also be a JPMS module, but not sure if that's possible.
2) have a `picocli-legacy?` (name TBD) jar containing both the core 
picocli package and the picocli.groovy package - similar to the 
current picocli-3.9.x jar


I believe the first option may be cleanest. Scripts would need to 
change their grape module from @Grab('info.picocli:picocli:$version') 
to @Grab('info.picocli:picocli-groovy:4.0.0') and that would bring in 
the transitive dependency on 'info.picocli:picocli:4.0.0', if my 
understanding is correct.


Can anyone see any drawbacks with this approach?
Would there be any point in additionally providing a `picocli-legacy` 
(name TBD) jar containing both the core picocli package and the 
picocli.groovy package, similar to the current picocli-3.9.x jar?


On a side-note, has anyone had any issues with putting the 
`module-info.class` in the root of the modular jar versus putting it 
in META-INF/versions/9/ in the jar?
Some people <https://github.com/moditect/moditect/issues/67> use 
META-INF/versions/9/ as a way to (hopefully) avoid issues with older 
tools unable to cope with the `module-info.class`. Does anyone have 
any experience with this?


Remko

Re: new GroovyCliBuilder

2019-05-24 Thread MG


Thanks Remko, I will switch the import & yes I do :-)

On 24/05/2019 19:39, Remko Popma wrote:
The new CliBuilder annotations API works well for both the Commons CLI 
and the picocli implementation.
(And I agree that the annotations API has some advantages over the 
previous DSL style, but that may be a matter of taste.)


Note that you can swap the implementation from Commons CLI to picocli 
by changing the import

from
import groovy.cli.commons.CliBuilder
to
import groovy.cli.picocli.CliBuilder
With the latter the usage help will show ANSI colors and gives some 
other features like the `cliBuilder.usageMessage 
<http://docs.groovy-lang.org/latest/html/gapi/groovy/cli/picocli/CliBuilder.html>` 
property to customize the usage help message.


Glad you like it! :-)


On Sat, May 25, 2019 at 2:11 AM MG <mailto:mg...@arscreat.com>> wrote:


Hi guys,

just wanted to say that I recently had to revisit some older Groovy script 
code in my project, and I took the opportunity to switch the old CliBuilder 
implementation to the new Picocli based one 
(http://docs.groovy-lang.org/latest/html/gapi/groovy/cli/commons/CliBuilder.html
) - and I can just say that it is an absolute joy to work with: Concise, 
elegant, and type safe G-)


import groovy.cli.commons.CliBuilder
import groovy.cli.Option
import groovy.cli.Unparsed

// Alternative is to use an interface and let Groovy instantiate a class 
instance from it
class MyOptions {
  boolean isTestRun
  @Option(shortName='h', description='output help info') Boolean help
  @Option(shortName='r', description='process regular entries') Boolean 
regular
  // etc (for supported types outside of Boolean see URL above)
  @Unparsed List remaining // all additional options given

  MyScriptOptions(boolean isTestRun) { this.isTestRun = isTestRun }
}
  


final cli = new CliBuilder(usage:'my_powerful_groovy_script')
def opts = new MyOptions(true)
cli.parseFromInstance(opts, args.split())  // From now on all cmd
line params can be accessed in a type safe manner

if(opts.help) {
  println cli.usage()
  System.exit(0)
}

if(opts.regular) {
  ...
}

Cheers,
mg

new GroovyCliBuilder

2019-05-24 Thread MG


Hi guys,

just wanted to say that I recently had to revisit some older Groovy script code 
in my project, and I took the opportunity to switch the old CliBuilder 
implementation to the new Picocli based one 
(http://docs.groovy-lang.org/latest/html/gapi/groovy/cli/commons/CliBuilder.html
) - and I can just say that it is an absolute joy to work with: Concise, 
elegant, and type safe G-)


import groovy.cli.commons.CliBuilder
import groovy.cli.Option
import groovy.cli.Unparsed

// Alternative is to use an interface and let Groovy instantiate a class 
instance from it
class MyOptions {
 boolean isTestRun
 @Option(shortName='h', description='output help info') Boolean help
 @Option(shortName='r', description='process regular entries') Boolean regular
 // etc (for supported types outside of Boolean see URL above)
 @Unparsed List remaining // all additional options given

 MyScriptOptions(boolean isTestRun) { this.isTestRun = isTestRun }
}
 


final cli = new CliBuilder(usage:'my_powerful_groovy_script')
def opts = new MyOptions(true)
cli.parseFromInstance(opts, args.split())  // From now on all cmd line 
params can be accessed in a type safe manner


if(opts.help) {
  println cli.usage()
  System.exit(0)
}

if(opts.regular) {
  ...
}

Cheers,
mg

Re: Static imports seem to win over a method in closure's delegate

2019-04-12 Thread MG

See http://mrhaki.blogspot.com/2009/10/groovy-goodness-static-imports.html

For Web GUI programming we use Groovy together with Vaadin, and I 
recently had some cases, where e.g. an anonymous class method calls a 
Groovy closure which calls a Groovy closure which calls a method of the 
orginal containing class. In these cases it can become hard to have the 
expected method get called, and I also found that (depending on the 
situation) either using import aliasing or introducing a uniquely named 
helper method in the right class can clear things up quick & easy.

Cheers,
mg

On 12/04/2019 23:14, Paul King wrote:

Using import aliases can be a good workaround for such a case.

On Sat, Apr 13, 2019 at 4:58 AM Jochen Theodorou <mailto:blackd...@gmx.org>> wrote:

On 10.04.19 16:05, Herrendorf Johannes wrote:
> Hi Groovy users,
>
> I’m currently building a DSL in groovy and found some strange
behaviour
> I have no explanation for: If a method pointer with name
"myMethod" is
> imported as static import and a closure has a delegate with a method
> "myMethod" and it's delegation strategy is set to
"DELEGATION_ONLY", the
> imported method is always called inside the closure - the delegate
> property seems to be ignored.

two things to always remember:
* closure delegation is a runtime mechanism, it has no influence on
static compiled features
* static imports are compiled statically

The later is not because we want this, but because we have to more or
less. And it is painful. I can imagine a system where this is not
required, but that is far from easy or efficient.

[...]
> import static mailinglist.SomeOtherClass.myMethod
[...]
>           // dispatched to SomeOtherClass.myMethod; correct
>          myMethod "Hello"
>          closureStuff {
>              // dispatched to SomeOtherClass.myMethod, but I
expected that
>                       // it's dispatched to
ClosureDelegate.myMethod instead
>              myMethod "Good Morning"
>          }
[...]
> Am I missing something or is this a bug? Thanks for your help in
advance!

In short it is a limitation. I am not sure we can really do something
against that.

bye Jochen

Re: Become a Groovy Ant GA-)

2019-04-01 Thread MG


Hi Daniel,

On 01/04/2019 02:55, Daniel.Sun wrote:

Thanks a lot for your donating to Friends of Groovy Open Collective,
every little helps.


Spot on - as Tesco has known since 1993 ;-)
https://www.creativereview.co.uk/every-little-helps/


Up to now, the fund can sponsor about 4.5 man-day work according to
the average salary of Java Developer:
https://www.indeed.com/salaries/Java-Developer-Salaries


Thank you for pointing that out. My idea, as I've said, is that the 
large number of Groovy users out there each give a little, so that the 
small number of people who do the actual work can be supported and 
Groovy thrives !
An ocean is made of a myriad of tiny droplets - so please spread the 
word GA-)


Cheers,
mg

Become a Groovy Ant GA-)

2019-03-31 Thread MG


Hi Groovy users,

I have recently decided to back the "Friends of Apache Groovy" Patreon

https://opencollective.com/friends-of-groovy

on the lowest ($5) level.

Here is why: It was clear to me that backing it on the $100 level did 
not feel compatible with our family income (and in turn the Missus ;-) 
), and that my max conceivable level would be in the $50 area. There are 
individuals that back at both these levels, and while I am grateful for 
that, I do not expect that a large number of people will do so. I also 
felt slightly intimitated by their willingness to invest so much money 
every month into a single open source project: Given that I pay 14 EUR 
per month for Netflix for my whole family, or 15 EUR for all of us for 
Spotify, or give 10 EUR per month to the WWF, or 3 EUR to avaaz, at 
least to me it felt slightly off.


So I am calling for everyone to become a Groovy Ant, spread the word, 
and fund this great language on a level that does not personally hurt, 
so that it might live long and prosper GA-)


Cheers,
mg

PS: Alas Patreon does not support backing on a regular basis through 
Paypal, which also threw me off at first (they claim technical 
difficulties). If you prefer to use Paypal, you might consider donating 
$50 for the year (2 months off ;-) ).

Re: Groovy file associations on Windows

2019-02-11 Thread MG

Just a general reminder: Not every company using Groovy has unrestricted 
internet access... :-)

Cheers,
mg

On 11/02/2019 14:11, Keegan Witt wrote:
Do folks using it really need it to be in the lib directory with all 
the other jars? Or could they just use Grapes/Grab?


If it's truly helpful, I can keep it.  I'm just wondering if it's 
overkill.


On Mon, Feb 11, 2019, 2:19 AM Paul King <mailto:pa...@asert.com.au> wrote:


I'd be inclined to keep GPars in the mix for now. It isn't
actively maintained but is still very useful in its current form
and I hope to put some time into it at some stage.

Cheers, Paul.


On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt mailto:keeganw...@gmail.com>> wrote:

In addition to removing projects that are no longer developed
from the Groovy Windows installer (Gpars, Gaelyk, Scriptom,
EasyB, Gant, GMock), I'm considering removing the exe files
from groovy-native-launcher
<https://github.com/groovy/groovy-native-launcher>. These
haven't been compiled in quite a while and are just another
thing to maintain.  As I see it, there are two primary
benefits these provide.

 1. Provide a way to create file associations so you can
double click a Groovy file, or run myFile.groovy instead
of groovy myFile.groovy.
 2. Hide the command window when launching GroovyConsole.

For #2, I can work around this with a VBScript file (or
NirCmd).  #1 doesn't have a good way to solve other than the
current native binary solution since Launch4J doesn't support
variable expansion
<https://sourceforge.net/p/launch4j/bugs/162/>.  My question
is, do many folks need this functionality? It's something I've
never personally used.  Please weigh in with your thoughts.

-Keegan

Re: [PROPOSAL]About creating open collective for Groovy programming language in the name of Groovy Community

2019-01-08 Thread MG




Am 08.01.2019 um 11:54 schrieb Paul King:


> (4) While sponsorship is below what we'd like and below what it
has been
> at some previous points in Groovy life, it isn't 0. We have several
> existing sponsors, e.g. OCI. The wording about the collective
should take
> that into consideration.

     Yep. OCI is a great company for Groovy! We always appreciate its
sponsorship.

      Let's imagine that would be really great if more people
involve into
developing Groovy, more big features(e.g. MOP2, async/await) are
completed
and hard issues(e.g. generics of STC) are fixed every year :-)


Totally agree with you, just suggesting the wording used is sensitive 
to existing players. I can help craft wording if needed.




Might be worth thinking about whether existing sponsors would consider 
giving their donation through the same channel ? Could have different 
tiers of sponsorship (gold, silver, etc), with respective logo sizes, 
etc to differentiate. Would lead to a greater exposure for them...
I guess it would also not be too hard to integrate a sponsor names or 
logos into e.g. Groovy console (if Apache allows that)...


Cheers,
mg

Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread MG


Hi,

out of curiosity (and because having a fat jar again might be 
conventient at some point in the future in my work environment (also no 
internet access)):


This solution proposed by Keith does not work
https://github.com/gradle/gradle-groovy-all
?

Cheers,
mg



Am 19.12.2018 um 23:33 schrieb Paul Moore:

On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:

Paul,

The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
that you can ship and run with java -jar

Gradle has a shadow plugin and Maven has a shade plugin to do just that.

Thanks. I'd come to the conclusion that Gradle was likely the solution
I should be looking at, and I've spent the evening trying to set up a
basic Gradle script that does what I want. After a lot of
experimentation, I came up with the following, which seems to do what
I want:

-- start build.gradle --

version = "0.1"

configurations {
 deploy
}

dependencies {
 deploy 'org.codehaus.groovy:groovy-all:2.5.4'
}

repositories {
 jcenter()
}

task copyDeps(type:Copy, group: "Custom", description: "Copies project
dependencies") {
 from configurations.deploy.collect { it.absolutePath }
 into "dest/lib"
}

task copy(type: Copy, group: "Custom", description: "Copies sources to
the dest directory") {
 from "src"
 include "*.groovy"
 into "dest"
}

task deploy(type:Zip, group: "Custom", description: "Build a deployment zip") {
 dependsOn copyDeps
 dependsOn copy
 from "dest"
 setArchiveName "${project.name}-${project.version}.zip"
}

-- end build.gradle --

It doesn't create a fat jar yet, but I can look into setting that up.
The various existing plugins seem to be dependent upon the
infrastructure set up by the java plugin, which I don't really
understand (or need, as far as I can tell) so they may not be of much
help. But I'm not sure what I need to do yet to write my own.
Something simple like

task customFatJar(type: Jar) {
 dependsOn copyDeps
 baseName = 'all-in-one-jar'
 from "dest/lib"
}

gives me an "all-in-one-jar.jar" that contains the dependency jars
directly included, rather than being unpacked. So there's more I need
to do here...

Paul

Re: Long String concatenation failed

I don't know if your specific case might be improved in the future, but in 
general Groovy supports e.g. operator overloading as well as DSL creation, 
which in turn means that it cannot always be 100% Java copy & paste compatible, 
even if it strives to do so as much as possible.
In any case it should not take long to refactor your code...
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  15:47  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
Long String concatenation failed 
mg: Yes, I saw that it's working, but still,
groovy should add sugar to java instead of removing support of working code in 
java as:String text= "0"+"1" +"2" +"3";
Which I'm getting error:javax.script.ScriptException: 
groovy.lang.MissingMethodException: No signature of method: 
java.lang.String.positive() is applicable for argument types: () values: 
[]Possible solutions: notify(), tokenize(), size(), size()
Can I open a bug in groovy for this?
On Tue, Sep 25, 2018 at 4:04 PM, mg  wrote:
You can have new lines, just move the "<<" oi the end of the previous line, so 
Groovy knows there is more coming (Groovy does not need end-of-line semicolons 
btw):
String text ="" <" << vars["id2"] << ""
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  14:54  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
Long String concatenation failed 
Thank for your answers, I still have some comments:mg: I don't want to have a 
huge line with 20 parameters that can't be seen on screen so I need new lines 
between parameters

Nelson, Erick: I don't need XML as the article suggest "
builder classes to create XML "

On Tue, Sep 25, 2018 at 3:39 PM, Nelson, Erick  
wrote:








No, I mean markup builder.
Mr Haki says it best….
http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
 
 

Erick Nelson
Senior Developer – IT
HD Supply Facilities Maintenance
(858) 740-6523

 
 

From: mg 

Reply-To: "users@groovy.apache.org" 

Date: Tuesday, September 25, 2018 at 5:19 AM

To: "users@groovy.apache.org" 

Subject: Re: Long String concatenation failed


 

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 


 



 Ursprüngliche Nachricht 


Von: Jmeter Tea 



Datum: 25.09.18 09:56 (GMT+01:00) 



An: users@groovy.apache.org 


Betreff: Long String concatenation failed



 






Hello,
I have to  concatenate a lot of variables in a script and I want to make it 
readable, but I failed to separate lines as in java, The following code doesn't 
compile due to:


Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:


Script1.groovy: 2: unexpected token: << @ line 2, column 1.


   << vars["id2"] << ""


 
Code:
String text ="" <" 
<< vars["id2"] << "";

 


Is there a workaround or a better way concatenation a string in groovy?


 


Related question:


https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables


 


Thank you

Re: Long String concatenation failed

You can have new lines, just move the "<<" oi the end of the previous line, so 
Groovy knows there is more coming (Groovy does not need end-of-line semicolons 
btw):
String text ="" <" << vars["id2"] << ""
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  14:54  (GMT+01:00) An: users@groovy.apache.org Betreff: Re: 
Long String concatenation failed 
Thank for your answers, I still have some comments:mg: I don't want to have a 
huge line with 20 parameters that can't be seen on screen so I need new lines 
between parameters

Nelson, Erick: I don't need XML as the article suggest "
builder classes to create XML "

On Tue, Sep 25, 2018 at 3:39 PM, Nelson, Erick  
wrote:








No, I mean markup builder.
Mr Haki says it best….
http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
 
 

Erick Nelson
Senior Developer – IT
HD Supply Facilities Maintenance
(858) 740-6523

 
 

From: mg 

Reply-To: "users@groovy.apache.org" 

Date: Tuesday, September 25, 2018 at 5:19 AM

To: "users@groovy.apache.org" 

Subject: Re: Long String concatenation failed


 

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 


 



 Ursprüngliche Nachricht 


Von: Jmeter Tea 



Datum: 25.09.18 09:56 (GMT+01:00) 



An: users@groovy.apache.org 


Betreff: Long String concatenation failed



 






Hello,
I have to  concatenate a lot of variables in a script and I want to make it 
readable, but I failed to separate lines as in java, The following code doesn't 
compile due to:


Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:


Script1.groovy: 2: unexpected token: << @ line 2, column 1.


   << vars["id2"] << ""


 
Code:
String text ="" <" 
<< vars["id2"] << "";

 


Is there a workaround or a better way concatenation a string in groovy?


 


Related question:


https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables


 


Thank you

Re: Long String concatenation failed

I replied to the original question and how to fix the the compile time error 
shown there, not your (valid) suggestion for a completely different approach... 
:-)
 Ursprüngliche Nachricht Von: "Nelson, Erick" 
 Datum: 25.09.18  14:39  (GMT+01:00) An: 
users@groovy.apache.org Betreff: Re: Long String concatenation failed 


No, I mean markup builder.
Mr Haki says it best….
http://mrhaki.blogspot.com/2009/10/groovy-goodness-creating-xml-with.html
 
 

Erick Nelson
Senior Developer – IT
HD Supply Facilities Maintenance
(858) 740-6523

 
 

From: mg 

Reply-To: "users@groovy.apache.org" 

Date: Tuesday, September 25, 2018 at 5:19 AM

To: "users@groovy.apache.org" 

Subject: Re: Long String concatenation failed


 

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 


 



 Ursprüngliche Nachricht 


Von: Jmeter Tea 



Datum: 25.09.18 09:56 (GMT+01:00) 



An: users@groovy.apache.org 


Betreff: Long String concatenation failed



 






Hello,
I have to  concatenate a lot of variables in a script and I want to make it 
readable, but I failed to separate lines as in java, The following code doesn't 
compile due to:


Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:


Script1.groovy: 2: unexpected token: << @ line 2, column 1.


   << vars["id2"] << ""


 
Code:
String text ="" <" 
<< vars["id2"] << "";

 


Is there a workaround or a better way concatenation a string in groovy?


 


Related question:


https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables


 


Thank you

Re: Long String concatenation failed

If it is just the CTE that is the problem, you just have ro move the "<<" to 
the end of the previous line... 
 Ursprüngliche Nachricht Von: Jmeter Tea  
Datum: 25.09.18  09:56  (GMT+01:00) An: users@groovy.apache.org Betreff: Long 
String concatenation failed 


Hello,I have to 

concatenate a lot of variables in a script and I want to make it readable, but 
I failed to separate lines as in java, The following code doesn't compile due 
to:Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: 
startup failed:Script1.groovy: 2: unexpected token: << @ line 2, column 1.   << 
vars["id2"] << ""
Code:
String text ="" <" 
<< vars["id2"] << "";
Is there a workaround or a better way concatenation a string in groovy?
Related 
question:https://stackoverflow.com/questions/47786399/jmeter-groovy-script-concatenation-of-variables

Thank you

Re: @MapConstructor + @CompileStatic on Static Inner Class => CTE


Might have been reported before. Will do.

On 04.09.2018 00:12, Paul King wrote:

Please create an issue. VerifyError is always a bug.

On Tue, Sep 4, 2018 at 4:55 AM MG <mailto:mg...@arscreat.com>> wrote:


The following code using @MapConstructor on a static inner class
raises
a compile time error (see end of mail; different error when making
the
inner class non-static):

import groovy.transform.CompileStatic
import groovy.transform.MapConstructor

@CompileStatic
class GroovyMapConstructorCheck {

 @MapConstructor(noArg = true)
 static class Goo {
 final String s0 = "text0"
 final int x0
 final String s1
 final String s2 = "TEXT2"
 final o0

 @Override
 public String toString() {
 return "Goo(|$s0|,|$x0|,|$s1|,|$s2|,|$o0|)"
 }
 }

 void go() {
 println new Goo()
 println new Goo(s0:"abc")
 println new Goo(x0:123, s0:"abc")
 println new Goo(s1:"S1", s2:"S2", x0:-999, o0:new Object(),
s0:"S0")
 final goo = new Goo(s1:"S1", s2:"S2", x0:-999, o0:new
Object(),
s0:"S0")
 }
}

final check = new GroovyMapConstructorCheck()
check.go()

/*
Compile time error:

java.lang.VerifyError: Bad type on operand stack
Exception Details:
   Location:
GroovyMapConstructorCheck$Goo.(Ljava/util/Map;)V @85:
invokevirtual
   Reason:
 Type 'GroovyMapConstructorCheck$Goo' (current frame,
stack[0]) is
not assignable to 'groovy/lang/Closure'
   Current Frame:
 bci: @85
 flags: { }
 locals: { 'GroovyMapConstructorCheck$Goo', 'java/lang/Object',
'java/lang/String', 'java/lang/String', 'groovy/lang/MetaClass' }
 stack: { 'GroovyMapConstructorCheck$Goo' }
   Bytecode:
 0x000: 2ab7 001b 121d 4d2c 2a5f b500 1f2c 5712
 0x010: 214e 2d2a 5fb5 0023 2d57 2ab6 0027 3a04
 0x020: 1904 2a5f b500 2919 0457 2bc7 0007 04a7
 0x030: 0004 0399 001a 03bd 0004 b800 2f3a 0519
 0x040: 0512 31b8 0035 c000 314c 1905 572a 2bb8
 0x050: 003b 0157 2ab6 0041 c000 4312 44b9 004a
 0x060: 0200 9900 232a b600 41c0 0043 1244 b900
 0x070: 4e02 003a 0619 06b8 0054 c000 562a 5fb5
 0x080: 001f 1906 572a b600 41c0 0043 1257 b900
 0x090: 4a02 0099 0020 2ab6 0041 c000 4312 57b9
 0x0a0: 004e 0200 3a07 1907 b800 5d2a 5fb5 005f
 0x0b0: 1907 572a b600 41c0 0043 1260 b900 4a02
 0x0c0: 0099 0023 2ab6 0041 c000 4312 60b9 004e
 0x0d0: 0200 3a08 1908 b800 54c0 0056 2a5f b500
 0x0e0: 6219 0857 2ab6 0041 c000 4312 63b9 004a
 0x0f0: 0200 9900 232a b600 41c0 0043 1263 b900
 0x100: 4e02 003a 0919 09b8 0054 c000 562a 5fb5
 0x110: 0023 1909 572a b600 41c0 0043 1264 b900
 0x120: 4a02 0099 001d 2ab6 0041 c000 4312 64b9
 0x130: 004e 0200 3a0a 190a 2a5f b500 6619 0a57
 0x140: b1
   Stackmap Table:

full_frame(@50,{Object[#2],Object[#70],Object[#86],Object[#86],Object[#108]},{})
 same_locals_1_stack_item_frame(@51,Integer)

full_frame(@77,{Object[#2],Object[#4],Object[#86],Object[#86],Object[#108]},{})
 same_frame(@133)
 same_frame(@179)
 same_frame(@228)
 same_frame(@277)
 same_frame(@320)


 at

GroovyMapConstructorCheck.go(MapConstructorCheck_inner_class_error.groovy:24)

 at GroovyMapConstructorCheck$go.call(Unknown Source)

 at

MapConstructorCheck_inner_class_error.run(MapConstructorCheck_inner_class_error.groovy:33)
*/

Re: @CompileStatic void method returns null ?

But the call to Foo#baz() coud return an e.g. GroovyVoidObject instance, 
which in turn throws a "cannot return void from method" if that happens 
to be the last expression in your example, no ?
It feels like returning null here is just a stopgap, not anything one 
actually wants to have in the language...

I don't expect the dynamic compiler to be changed, but should we really 
mirror the dynamic comiler behavior in the static compiler in this case 
? I think it would be much more least surprise in the @CompileStatic case...

Cheers,
mg

PS: Calling void methods better be fine, otherwise why do they exist in 
the first place ;-)  - I am/was always referring to my initial question, 
so the whole thread is about expecting/using void method call results 
somewhere...

On 04.09.2018 01:41, Paul King wrote:

Calling void methods is fine. Expecting a result is the point in question.

For dynamic Groovy, you can't always tell which case you have:

class Foo {
  def bar() { 42 }
  void baz() { }
}

def method(boolean condition, delegate, meth1, meth2) {
  if (condition) delegate."$meth1"()
  else delegate."$meth2"()
}

println method(true, new Foo(), 'bar', 'baz') // 42
println method(false, new Foo(), 'bar', 'baz') // null

Here, "method" is expecting to return some value that happens to be 
the last expression, i.e. the result of the if/then/else expression, 
so we return null in such cases.

Cheers, Paul.

On Tue, Sep 4, 2018 at 7:38 AM MG <mailto:mg...@arscreat.com>> wrote:

What I meant was: What sense does letting void methods be called make
for the dynamic case, i.e. the dynamic compiler ? From a programmer's
perspective, i.e. what is a programming use case for that
feature/behavior, in dynamic Groovy ?

Of course I can do the following in dynamic Groovy:

// Groovy 2.5.0
class Goo {
 //void nogoo() { return 123 } // Dynamic Groovy compiler:
RuntimeParserException: Cannot use return statement with an
expression on a method that returns void
 void nogoo() { 123 }
}

final goo = new Goo()

println "original: goo.nogoo()=${goo.nogoo()}"

goo.metaClass.nogoo = { return 456 }

println "mopped: goo.nogoo()=${goo.nogoo()}"

Which will build, run, and output

original: goo.nogoo()=null
mopped: goo.nogoo()=456

  i.e. returning 456 from a void method in the second case.
But if I am using a library that includes the Goo class, why would I
ever expect a return value from the nogoo method (and therefore call
it), considering its return type is void ? And if I control the Goo
class myself, why would I not just change its return type to int
or def ?

Cheers,
mg

On 03.09.2018 22:36, Jochen Theodorou wrote:
> On 03.09.2018 17:13, mg wrote:
>> But in what scenario does the dynamic behavior make sense ?
>
> for a static compiler? none other than being compatible
>
> bye Jochen
>

Re: @CompileStatic void method returns null ?

What I meant was: What sense does letting void methods be called make 
for the dynamic case, i.e. the dynamic compiler ? From a programmer's 
perspective, i.e. what is a programming use case for that 
feature/behavior, in dynamic Groovy ?


Of course I can do the following in dynamic Groovy:

// Groovy 2.5.0
class Goo {
    //void nogoo() { return 123 } // Dynamic Groovy compiler: 
RuntimeParserException: Cannot use return statement with an expression on a 
method that returns void
    void nogoo() { 123 }
}

final goo = new Goo()

println "original: goo.nogoo()=${goo.nogoo()}"

goo.metaClass.nogoo = { return 456 }

println "mopped: goo.nogoo()=${goo.nogoo()}"


Which will build, run, and output

original: goo.nogoo()=null
mopped: goo.nogoo()=456

 i.e. returning 456 from a void method in the second case.
But if I am using a library that includes the Goo class, why would I 
ever expect a return value from the nogoo method (and therefore call 
it), considering its return type is void ? And if I control the Goo 
class myself, why would I not just change its return type to int or def ?


Cheers,
mg


On 03.09.2018 22:36, Jochen Theodorou wrote:

On 03.09.2018 17:13, mg wrote:

But in what scenario does the dynamic behavior make sense ?


for a static compiler? none other than being compatible

bye Jochen

@MapConstructor + @CompileStatic on Static Inner Class => CTE