Using Java 22; this worked before. What did change w.r.t. Java, Groovy?

Do you explicitly subclass and it worked before? Or is this error complaining about something under the covers?

I did not subclass it; I just use(d) the following at toplevel

record Vector2d(float x, float y) { }

This worked before

But I guess it is more on the Eclipse (IDE) side of things?

(as almost always 😞 )

Maybe create an issue anyway and Eric might have further thoughts. I don't think he frequents slack much (if at all). And we can close if we definitely believe it's on the Eclipse side of things.

Or send to the dev mailing list

OK, thx Paul

I'm trying to debug an issue with the static type checker and closure method parameters. It seems like in Groovy 4.0.19, something changed that has broken type checking for statements like:

cfValues['SpecialKey']*.name.collect {it.toUpperCase()}

Some context:

cfValues

is a binding variable that I provide custom type information for via a

ClassCodeExpressionTransformer

. In this case, the static type checker seems to know that

cfValues['SpecialKey']

returns a value of the expected type which, in turn, has a

name

property that is a String. Statements like:

cfValues['SpecialKey']*.name*.toUpperCase()

compiles just fine. But from Groovy 4.0.19 onward, the static type checker only seems to think that the

it

Closure parameter is an

Object

, not a

String

. I've been poring over the diff and stepping through the debugger to figure out what changed, but I haven't been able to fathom it out. Does this ring a bell for anyone?

Jonny, do you want to send your last query to the mailing list. I could try to dive into what might have changed but Eric might know off the top of his head. He doesn't visit slack much, if at all.

Sure, Paul! dev@groovy.apache.org?

Hi! I'm having an issue with a NPE on a class using @CompileStatic, when using StringBuilder with null Integer/Long values. Tested with Gradle 8.13, using:

implementation 'org.apache.groovy:groovy:4.0.27'

Also happens with Groovy 3.x, which is where I hit the issue (it's a Grails app). Short example code:

import groovy.transform.CompileStatic

@CompileStatic
class SomeClass {

    String desc
    Integer int1
    Long long1

    @Override
    String toString() {
        return new StringBuilder('SomeClass{')
                .append('desc=').append(desc)
                .append(', int1=').append(int1)
                .append(', long1=').append(long1)
                .append('}')
                .toString()
    }

}

static void main(String[] args) {
    println new SomeClass(desc: 'desc', int1: 1, long1: 2).toString() // works
    println new SomeClass().toString() // causes NPE with @CompileStatic
}

Should I report this on JIRA? Though I don't have access to it and I'm short on time right now. Thanks!

Your issue involves a NullPointerException (NPE) in a Groovy class using @CompileStatic when appendingnull Integer or Long values to a StringBuilder in a Grails application. This occurs with Groovy 4.0.27 andearlier 3.x versions, tested with Gradle 8.13. Below, I’ll analyze the problem, provide a solution, and addresswhether you should report it, considering your time constraints and lack of JIRA access. I’ll also tie this to yourearlier context (reconnecting with a Grails.org friend) if relevant.

Is it intended and expected, that with

println(/\u21a/)  // 1
println(/\u21aX/) // 2
println(/\u21aF/) // 3
println('\u21a')  // 4
println('\u21aX') // 5
println('\u21aF') // 6

the result is 1 - a backslash followed by 4 characters 2 - a backslash followed by 5 characters 3 - the "Downwards Zigzag Arrow" character 4 - compile error complaining about the first single-quote as unexpected character 5 - compile error complaining about the first single-quote as unexpected character 6 - the "Downwards Zigzag Arrow" character ? For Java the Unicode escapes are evaluated and replaced before the actual source code parser kicks in and it complains about incomplete or wrong Unicode escapes, complaining about the second single-quote in code according to 2 / 4, and about the X in code according to 3 / 5, even if it is found in code comments. In Java you could for example also use

void foo\u0058bar()

to declare a method called

fooXbar

due to Unicode escapes being resolved and replaced before the parser kicks in, while in Groovy this does not work as it is handled as part of the parser. I mainly ask about 1 and 2 as I'm going to report an IntelliJ IDEA issue as the IDE complains about illegal escape sequence which is a false-positive in that case. And if 1 and 2 is intended, then I tend to question 3, as the backslash does not loose its meaning within the slash-y String in that case.

@paulk_asert has updated Groovysh to JLine3 in the PR: https://github.com/apache/groovy/pull/2263

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?