It is amazing. I can not wait to share with you all.

Random observation: I was using the

groovyConsole

to prepare code demos for a presentation to a local meetup. Quite a few times, the application would just freeze up and had to be forcefully shutdown. Seems like there is a memory leak?

Fortunately I didn’t run into any issues during the actual event. It seemed to happen only when left running for a long period of time.

Also the

groovysh

throws a bunch of deprecation warnings during start up. This was with Groovy 4 on JDK 17.

Please submit a JIRA ticket with some script to reproduce the issue.

Just curious if the JIRA issues have some kind of an indicator of being a “good first issue”.

Hi Team, I created GROOVY-11729 last week. Paul King has mentioned that he will free up some time next week to look into this. In the meantime, can someone please look into this and provide input? The impact of the issue is severe in our customer environments. So, appreciate if you could look into the issue.

Maybe I'm just too tired. If I have

Thread.start {
   new AutoCloseable() { void close() {} }.withCloseable {
      return
   }
   println("not to be displayed")
}.join()

How do I

return

from the

start

closure, not the

withCloseable

closure, so that the out line is not displayed?

The Groovy track in Apache CoC North America looks great. Anyone know if it will be recorded and made available later?

We will be making all the slides available. We don't currently have plans to record video but we'll be on the lookout for a way to make that happen.

Hey folks, it looks like http://groovy-lang.org/ is down for a few hours already and I'm not sure where to report that... maybe here is a good place? are you aware and is there some status page I could follow?

I'm experiencing very 'odd' behaviour in a large Groovy/Grails application that I'd like to pass by the experts here. When this application is run on a relatively low-spec CPU (25% of an M1 processor), not only does it go slow, but it appears to encounter 'deadlocks', or at least very very long locks, on certain operations. By long I mean a web request that should respond in a second or so time takes 10's of minutes, naturally causing the Session to timeout. I investigated this by observing the active java threads, taking a heap dump and stack trace following an abandoned automated test that attempted but failed to log-in but left the application consuming all the CPU that had it was allocated. I identified what I believe to be the 'stuck' thread, being an http-nio... thread that dispatch a request thru' a controller action that eventually updates a GORM object. Within the constraint evaluation of the GORM object it get stuck, parked obtaining a lock on a meta-class. And there it stays. The stack trace head is:

Thread 'http-nio-0.0.0.0-8080-exec-1' with ID = 74

jdk.internal.misc.Unsafe.park(Unsafe.java)

java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)

java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)

org.codehaus.groovy.util.LockableObject.lock(LockableObject.java:38)

org.codehaus.groovy.reflection.ClassInfo.lock(ClassInfo.java:393)

org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:313)

org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:258)

org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:1066)

org.codehaus.groovy.runtime.DefaultGroovyMethods.newInstance(DefaultGroovyMethods.java:18029)

org.grails.datastore.gorm.validation.constraints.factory.DefaultConstraintFactory.build(DefaultConstraintFactory.groovy:55)

grails.gorm.validation.DefaultConstrainedProperty.instantiateConstraint(DefaultConstrainedProperty.groovy:692)

grails.gorm.validation.DefaultConstrainedProperty.applyConstraint(DefaultConstrainedProperty.groovy:651)

org.grails.datastore.gorm.validation.constraints.builder.ConstrainedPropertyBuilder.createNode(ConstrainedPropertyBuilder.java:150)

groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:90)

org.grails.datastore.gorm.validation.constraints.builder.ConstrainedPropertyBuilder.doInvokeMethod(ConstrainedPropertyBuilder.java:63)

groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:74)

org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeOnDelegationObjects(ClosureMetaClass.java:424)

org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:348)

org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:61)

org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:51)

org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:171)

org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185)

The system was otherwise completely quiescent, and it was a long time (10's of minutes) between abandoning the test to getting around to digging the above stack trace out. It did eventually 'go away', as after a very long time I noticed the CPU utilisation had dropped down to almost nothing, and so I took another heap-dump and noticed all the http-nio threads were neatly parked, quiescent. So my question for groovy/gorm experts is, what could cause such lock contention? Has there ever been such issues in the core of Groovy around meta-class locking in the past that might provide some clues? Note, that when the same application is run 'at full speed', on the same Apple silicon, no issues arise, and indeed even at 1.5CPUs I think it runs ok - it's as if, below some threshold value, some kind of 'busy-wait-retry' mechanism is spinning the CPU it has, but not achieving the condition it needs to 'unlock'...? Thanks in anticipation for any ideas and suggestions. Regards, PaulB

I am upgrading a Groovy application but have run into an issue with date parsing, the following code parsing a danish date doesn't work after upgrading from Java 8 -> 11+

Date.parse('yyyy-MMM', '2011-Okt')

java.text.ParseException: Unparseable date: "2011-Okt"

Java changed date parsing in Java 9, I have found answers suggesting setting

-Djava.locale.providers=COMPAT,SPI,CLDR

should bring back support for Java 8 formats - but it doesn't seam to work... Will I have to rewrite the code, or is there a JVM setting I am missing?

Is it true that some code that was complied using Groovy 3 is not able to be run on Groovy 4? https://docs.gradle.org/current/userguide/upgrading_major_version_9.html#super_methods_may_be_inaccessible_from_groovy_3_x_code states for example that Groovy 4 resolves

super

calls differently and that code compiled with Groovy 3 misses runtime code for locating them. That would be quite a breaking change making many Groovy 3 compiled code unusable on Groovy 4. 😕 I don't find something about

super

in the Groovy 4 release notes. For example quite some Gradle plugins are written in Groovy and will break now with Gradle 9 which embeds Groovy 4 if they are not being recompiled and then either released with two variants or drop support for Gradle <9. 😕

I couldn't see the issue mentioned in the release notes either. I'll track the issue down and add it (if indeed it isn't there). From memory, if it's the issue I believe it is, the workaround is to isolate the call to super in a @CompileStatic method. That should work on both Groovy 3 and 4. I realize that doesn't help existing plugins in the wild, but JVM accessibility changes forced us to make the change.

Yes, seems to be that issue where the receiver for the

super....

call is different when compiled with 4 vs 3 but 4 requires the new one no-matter what and a

CompileStatic

helps if possible. But to me it is really concerning tbh. that there is such a big breaking change that makes many Groovy-compiled libraries unusable and then it did not even make it to the release notes. 😕 Of course it would be better to use

CompileStatic

in all library or plugin code anyway, and if only for runtime speed, but I'd bet there are also many out there that do not use it. 😕

Anyway, thanks for confirming

I believe this is the issue: https://issues.apache.org/jira/browse/GROOVY-8693 This also has some further discussion: https://issues.apache.org/jira/browse/GROOVY-11193 GROOVY-8693 didn't have the breaking label, so wasn't picked up for the release notes. I have changed that now. Also, I may have misremembered the reasoning earlier in this thread. I thought security permissions was in the mix but perhaps it was just the flawed assumptions on the Groovy side about the possibility of default methods in interfaces being selected as the sender. I don't think the significance of this issue was fully understood right away or we might have further explored one idea at the time which was adding some metainformation about a mop version into the bytecode and flipping between versions if needed by maintaining all the old code - flawed as it was for numerous edge cases.

Given this snippet:

trait Foo {
  def foo(Object o) {
    println("foo(o)")
  }
  def foo(Map<String, Object> m) {
    println("foo(m)")
  }
}
class Bar implements Foo {
  def bar(Object o) {
    println("bar(o)")
  }
  def bar(Map<String, Object> m) {
    println("bar(m)")
  }
}
new Bar().with {
  foo((Object) null)
  foo(null as Object)
  bar((Object) null)
  bar(null as Object)
}

In Groovy 2.5, 3.0 and 4.0

bar

uses the

Object

variant as expected, but

foo

uses the

Map

variant for some reason. This most probably was a bug, because in Groovy 5.0 now both use the

Object

variant as expected. Is there any way to get the right behavior also with 2.5 - 4.0? (Context: Due to the inability to call the package-private methods in Groovy 5 anymore, I'm trying to move all the

...Impl

methods to a trait and coerce the

Specification

to that trait to call the

...Impl

methods, so that I don't have to broaden the method visibility and thus pollute IDE completions for Specifications with implementation details that only get used through AST transformation. I was quite successful until there happened to be a test that does exactly the shown and now fails with a

NullPointerException

as the

Map

argument is expected to be non-

null

.)

Dear all, just realized that Groovy 5 is out. IYO: What are the most important features/changes of Groovy 5?

In a class (

Mixin

) written in Java, that is used as a

mixin

for another class (

Mixedinto

) written in Java, how do I (

Mixin

) coerce

this

to the instance I am mixed into (

Mixedinto

)? If the

Mixin

class would be Groovy, I would just do

this as Mixedinto

and it works. So I thought I should be able to use

DefaultGroovyMethods.asType(this, Mixedinot.class)

, but that does give a

GroovyCastException

. 😞

Wth does this want to tell me, that I did something wrong or that Groovy 5 has a bug?

java.lang.IncompatibleClassChangeError: Type spock.util.AstNodeToScriptVisitor$_visitClass_closure11$_closure49 is not a nest member of spock.util.AstNodeToScriptVisitor: current type is not listed as a nest member

That was with Java 11. With Java 17 it changes to

java.lang.IllegalAccessError: class spock.util.AstNodeToScriptVisitor$_visitClass_closure11$_closure49 tried to access private method 'void spock.util.AstNodeToScriptVisitor.visitObjectInitializerBlocks(org.codehaus.groovy.ast.ClassNode)' (spock.util.AstNodeToScriptVisitor$_visitClass_closure11$_closure49 and spock.util.AstNodeToScriptVisitor are in unnamed module of loader 'app'), (Type spock.util.AstNodeToScriptVisitor$_visitClass_closure11$_closure49 (loader: 'app') is not a nest member of type spock.util.AstNodeToScriptVisitor (loader: 'app'): current type is not listed as a nest member)

which makes even less sense. A Closure in a class is not allowed to call a

private

method in that class? o_O

Do you want to send that to the Dev mailing list. I'm on vacation this week and Eric doesn't frequent slack much.

I'll send it to Jira when the rest of Spock is working. I learned what nest members are today, and that Groovy with static compilation seems to not properly define the nest members with Closures, but I was not able to reproduce it in an MCVE. Switching off static compilation for that method helped as work-around for now. Enjoy your vacation and thanks for answering anyway. :-)

Eric says "The nest member stuff required reordering the classes in the compilation unit so the nest host is processed after all nest mates. Closure inner classes are not created at the time classgen runs on the containing class. JVM spec said that dynamic nest mates works starting in like Java 16. I'm not sure if that is why they get two different results. The very latest 5.0.2 snapshot has the best order compromise that I could come up with. If the spock folks have a test case, I could give it a look."

But a JIRA would be great.

I now also verified that it still happens with

5.0.2-SNAPSHOT

as available on https://repository.apache.org/content/repositories/snapshots/

New problem. Due to the wrong overload resolution in traits, I switched to using a mixin. This works fine in the main tests, but in some other test task it fails with not finding the mixin methods and I have no idea why. The

ExpandoMetaClass

of

Specification

does have the methods from the mixin. Though I'm standing at a breakpoint in (Groovy 3 right now)

groovy.lang.MetaClassImpl#getMethodWithCachingInternal

. In the working process the

metaMethodIndex.table

does have an entry for the mixin method. In the broken process it is missing. Any idea someone how to find out what is going wrong here / where to debug best?

Is it expected or a bug that since Groovy 4 a

Boolean isCleanTag()

can no longer be access using

.cleanTag

? I don't see any mention in the release notes.