ConfigSlurper

defaults to using a

new GroovyClassLoader()

, which uses

Thread.currentThread().getContextClassLoader()

as its parent. That results in the following

MissingMethodException

, if the

Script

class was loaded by a different

ClassLoader

, e.g., by running the following example script:

def ct = Thread.currentThread()
def originalCCL = ct.contextClassLoader
def newCL = new URLClassLoader(originalCCL.parent.parent.URLs, (ClassLoader) null)
def gls = 'groovy.lang.Script'
assert originalCCL.loadClass(gls) != newCL.loadClass(gls)

ct.contextClassLoader = newCL
def config = new ConfigSlurper().parse('foo = 42')

Caught: groovy.lang.MissingMethodException: No signature of method: groovy.util.ConfigSlurper.parse() is applicable for argument types: (Script_35210c81fc1d6f48d278c8cf2137664d) values: [Script_35210c81fc1d6f48d278c8cf2137664d@4c6daf0]
Possible solutions: parse(groovy.lang.Script), parse(java.lang.Class), parse(java.lang.String), parse(java.net.URL), parse(java.util.Properties), parse(groovy.lang.Script, java.net.URL)

Is that the intended behavior? The

new ConfigSlurper().classLoader

can be overridden, but would it be better to default it to

new GroovyClassLoader(this.class.classLoader)

?

Dear all, Kotlin code:

var str = buildString {

append("Hi")

append(" ")

append("there)

}

What is the equivalent, or can this be “emulated” or written directly in Groovy? See https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.text/build-string.html

@bsdooby you could use Groovy's leftShift operator instead of append, like this:

StringBuilder sb = new StringBuilder()
sb << "Hi"
sb << " "
sb << "there"
String str = sb.toString()

If you want something closer to the Kotlin thing one way of doing it might be:

String buildString(@DelegatesTo(StringBuilder) Closure<?> fn) {
	StringBuilder sb = new StringBuilder()
	fn.delegate = sb
	fn()
	return sb.toString()
}

String str = buildString {
	append("Hi")
	append(" ")
	append("there")
}

@Poundex Cool, that would be the second version then!

THX

@bsdooby How about:

def str = new StringBuilder().with {
    append('Hi')
    append(' ')
    append('there')
}.toString()

Also a nice way. Need to wrap my head around the differenct approaches (what

with

entails)

It’s somewhat ironic, but it’s one of the many features where Kotlin was very much inspired from Groovy 🙂

I opened https://github.com/oracle/graal/issues/10200 based on the previous discussion in December 2023. Since the groovy slack space only keeps records for 90 days, I can't see the previous discussion on groovy 5.0.0 under the graalvm native image.

@Ling Hengqian With a little luck you can find what you're looking for in the archive: https://groovy.linen.dev/

Got a challenge around a historical use of @Grab, and trying to find clever workarounds and don't see any good ones. We've added a second file which does @Grab with the same artifact and we're getting intermittent:

06:45:39  java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: org.mongodb#mongodb-driver-core;3.8.2: java.util.ConcurrentModificationException at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1043)]

We've kinda got to keep both the old and the new file for backward compatibility, and they both need the same imports. So, is it possible the

initClass=false

option might solve this problem? What might the side effects of this flag be?

@paulk_asert or anyone else, when using @Grab with initClass=false, when does the download and classpath modification happen? If it's not during static initialization, then i wonder how it can even work.

@paulk_asert people cannot answer in #C2LNH2CTS 😉 The domain registry entry was updated 4 hours ago, so hopefully it will get back up soon? https://store.nic.com/whois?domainName=groovycommunity.com

Is the GPars project abandoned now? https://github.com/GPars/GPars . I see someone started updating it for newer versions of groovy here: https://github.com/woodmawa/GPARS_v2. Does anyone have history here?

When using the

@Delegate

annotation, for example:

static GebTestManager testManager

@Delegate
Browser getBrowser() {
    testManager.browser
}

(Browser is a Groovy class from Geb 6.0 library). I am not managing to get the original parameter names into the generated delegation methods from

Browser

. For example, for `Browser.go(String url)`the following is generated:

@Generated
public void go(String param0) {
    CallSite[] var2 = $getCallSiteArray();
    var2[307].call(var2[308].callCurrent(this), param0);
}

Is there a way to help the compiler retain the original parameter name? I have tried (with variations and combinations of) the following in the Gradle build script:

tasks.withType(GroovyCompile).configureEach {
    options.debug = true
    options.compilerArgs << '-parameters'
    groovyOptions.parameters = true
    groovyOptions.optimizationOptions['parameters'] = true
}

I'm using Groovy 3.0.23 and Java 11.

Hi folks, the following code is working with grails 6 (Groovy 3), but it stopped working with Grails 7 (Groovy 4). NOTE:

securityService

has a method called

isLoggedIn()

.

if (securityService.loggedIn) {

to make it work I need to call the getter explicitly:

if (securityService.isLoggedIn()) {

Is there a reason for it?

Okay I figured it out. I cannot decalre a method returning a

Boolean

it has to return a

boolean

. Is this behaviour somehting we want from Groovy or it is a bug?

I wonder (idk); what’s the difference between the two?

In an AST transformation I replaced

binExpr.getRightExpression()

by

new MethodCallExpression(binExpr.getRightExpression(), "iterator", new EmptyExpression())

but now I get during "Class Generation" phase

Unable to produce AST for this phase due to an error:

BUG! exception in phase 'class generation' in source unit 'script1741057086260.groovy' Error while popping argument from operand stack tracker in class Foo method java.lang.Object $spock_feature_0_0prov0().

Fix the above error(s) and then press Refresh

Any idea why I get this or how to investigate?

I've been working on a LSP and Syntax Highlighting for my Groovy-based web framework (which happens to have its own template-engine). Will for sure adjust the contrast, but I've been pleased with Sublime's language-within-language highlighting capabilities and the ability to add rules to highlight my injected reactive and server-action bits. I'm usually coding with IntelliJ—I've been abusing the Grails plugin to highlight my templates so far—but there are oddities at this point due to some of the differences, so I wanted to see if I could pull off something basic to start with. 😅

Hi folks, does anybody know if the groovy4 branch would get ASM updated to 9.8 for jdk25 compatibility?

We upgraded one of our applications to groovy 3.0.24 today but ran into an odd error:

$ sdk use groovy 3.0.24
Using groovy version 3.0.24 in this shell.
$ groovy
/usr/bin/env: 'sh\r': No such file or directory
/usr/bin/env: use -[v]S to pass options in shebang lines

Tested on MacOs and Linux

(In a multimodule maven build) with maven-jar-plugin one can create a reusable test-jar f.e. To share common test fixtures. This is easy to configure for java classes. For groovy classes it does not seem to work out of the box. What am I missing?

Hey everyone! We're using Groovy inside ScriptRunner (Jira plugin) and I'm hitting package-conflict woes. One of our Groovy scripts is annotated with

@WithPlugin()

, which (according to the SR docs) adds a named Jira plugin's ClassLoader to (much to our chagrin) the root ClassLoader for all scripts (versus the annotated one). One of the plugins we're doing this with ships a really old version of Apache commons-csv (we're not even using it ourselves, but I guess it's in their dependency chain), whereas another one of our scripts (not using

@WithPlugin()

) fetches a more recent version from maven-central via

@Grab()

. The older version isn't forwards-compatible due methods added in more recent versions. I'm still pretty new to Groovy - in .NET, we have AssemblyLoadContexts, binding redirects, and other tools to alleviate problems like these. Searching "parent-last classloader" seems to get a lot of responses for Java proper, but it's not clear if that's: • applicable to Groovy • safe to do • already implemented with prior art Can someone help me understand what I'm missing?

How can this happen?

groovy.lang.MissingMethodException: No signature of method: geb.navigator.DefaultNavigator.ensureContainsAtMostSingleElement() is applicable for argument types: (String) values: [text]
	at app//org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
	at app//geb.navigator.DefaultNavigator.methodMissing(DefaultNavigator.groovy:811)
	at java.base@11.0.24/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base@11.0.24/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base@11.0.24/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base@11.0.24/java.lang.reflect.Method.invoke(Method.java:566)
	at app//org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
	at app//groovy.lang.MetaClassImpl.invokeMissingMethod(MetaClassImpl.java:924)
	at app//groovy.lang.MetaClassImpl.invokePropertyOrMissing(MetaClassImpl.java:1413)
	at app//groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1335)
	at app//groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1088)
	at app//groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1142)
	at app//groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
	at app//groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:165)
	at app//org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
	at app//geb.navigator.DefaultNavigator.text(DefaultNavigator.groovy:622)
	at java.base@11.0.24/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base@11.0.24/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base@11.0.24/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base@11.0.24/java.lang.reflect.Method.invoke(Method.java:566)
	at app//org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:343)
	at app//groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:328)
	at app//groovy.lang.MetaClassImpl.doInvokeMethod(MetaClassImpl.java:1333)
	at app//groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1088)
	at app//groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1142)
	at app//groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1007)
	at app//groovy.lang.DelegatingMetaClass.invokeMethod(DelegatingMetaClass.java:165)
	at app//org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
	at app//geb.junit5.ParallelExecutionTest.testRunningIterationsInParallel(ParallelExecutionTest.groovy:90)
	at java.base@11.0.24/java.lang.reflect.Method.invoke(Method.java:566)
	at java.base@11.0.24/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
	at java.base@11.0.24/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
	at java.base@11.0.24/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
	at java.base@11.0.24/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
	at java.base@11.0.24/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

The code is this: https://github.com/apache/groovy-geb/blob/fc4130b3f190d9a98f4ba0bddad2d03fe64733b3[…]/geb-core/src/main/groovy/geb/navigator/DefaultNavigator.groovy So the code at line 622 is calling the method in line 854. So to my understanding it should not even go to

methodMissing

but directly invoke the method.

I don't see any reason why that should happen.

Yeah, well, it happened. Probably some really nasty race condition. As I said (in the thread) it happened once after 1136 tries.

Currently it is at 282 after starting again

Ok, another 10_000 runs later all runs were successful. Let's just attribute it to a bit-flip for now. 😄