Can you pull and retry

So, I'm trying to tweak the Groovy compiler so that, for a specific set of methods on a specific class, I can override the return type. I started with a Type Checking Extension, and that isn't quite working as I'd expect. I'm thinking an AST Transform in the SEMANTIC_ANALYSIS phase might be more suitable. I'll post some more details in a thread, but any pointers would be appreciated.

Is there a reason GDK does not add a

size

method to

java.util.stream.Stream

? And is there a reason

NioExtensions#eachFile(Path, Closure)

does not have a

@ClosureParams

annotation?

It should probably have

size()

as an alias for

count()

. It would have the same caveats as

count

in terms of side-effects/infinite streams.

That's what I did expect, yeah

For

NioExtensions#eachFile(Path, Closure)

, it should have the same closure params as

NioExtensions#eachFile(Path, FileType, Closure)

. I presume just an oversight.

Thought so. It might also be the cause that IJ thinks a

File

is the argument. 🤷‍♂️ https://youtrack.jetbrains.com/issue/IDEA-373956

What is the type hint if you add the FileType param?

Yeah, just tried it and it is Path with a FileType added.

Were you keen to create issues/PRs or happy if I do that?

I'm fine with you fixing the two issues right away, thx. :-)

Do you also take care of the Stream.size? 🙂

In the newest Eclipse 2025-06, I get the following error in a Groovy script where a (Java native) Record type is declared:

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.