groovy-lang.org seems to be down again

can we have a method like this in groovy?

Duration duration = measureTime {
   //code
} 

Long duration = measureTimeMilis {
   //code
}

Sure:

long timeMillis(Closure c) {
    long start = System.currentTimeMillis()
    c.call()
    System.currentTimeMillis() - start
}

Long duration = timeMillis {
    println 'Hi'
    sleep 500
    println 'Bye'
}

println duration
// Hi
// Bye
// 507

System.currentTimeMillis()

should never be used to measure a duration within one JVM though, as it depends on wall-clock, so is affected by time-synchronization, summer-time-change and so on. Always use

System.nanotime()

to measure durations within the same JVM.

What I mean is, I use this method a lot in almost all my projects; I think it would be useful if it were included in the standard Groovy library. I'm sure it would help others.

Okay, now I see what you meant. Sure, a utility based on nanoTime would be a possibility.

Thanks @paulk_asert

I created this request: https://issues.apache.org/jira/browse/GROOVY-11947

Feel free to comment or suggest improvements. We'd probably target Groovy 6 in the first instance and backport based on a risk assessment, e.g. would those methods likely exist currently in user code.

Hello, code that worked on groovy 5.0.4 is now throwing MethodTooLargeException from MethodWriter.java:2088, but AFAIS the method is not too large

Stumbled upon this recently: https://jactl.io/blog/2026/03/16/groovy-vs-jactl

I understand Jactl is targeting a different problem. But are there any good ideas there we could use for Groovy 6?

I like most of jactl features, especially pattern matching and destructuring. Groovy has not supported pattern matching and destructuring fully for now, but it's better support the feature to improve compatibility with Java.

BTW, Groovy 6 has been trying to improve performance.

Speaking of Groovy 6; is there a roadmap of features, planned for this release?

Sure is - it's in the website repo. I'm doing some tweaking and will ensure a published version is also available shortly. The current version is here: https://groovy-lang.org/releasenotes/groovy-6.0.html

@paulk_asert Merci beaucoup!

Hi team! I’ve identified a significant shift in Groovy 5 regarding “file truth” semantics (GROOVY-10949). In the new version, a

File

object evaluates to

false

if the file does not physically exist, whereas previously it only required the reference to be non-null. While this change impacts the Nextflow codebase, our primary concern is the broader ecosystem: • Critical External Impact: This change is a “silent breaker” for the thousands of third-party scripts and applications running on Nextflow. Users expecting legacy Groovy behavior will encounter unexpected logic failures that are notoriously difficult to debug in a pipeline context. • Internal Management: While we can refactor our own core codebase to accommodate the new semantics, we cannot realistically control or force a synchronized update across the entire community of external plugins and user-maintained pipelines. To mitigate this, I’ve submitted this PR to introduce a system option that allows reverting to the previous behavior. This ensures backward compatibility and provides a necessary safety net for the community as they transition. Hope you will consider this for merge!

Sounds like a useful flag to have. I left some comments on the PR.

@paulk_asert Groovy website struggles to load for me right now

let me take a look

should be okay now

👍

Hello everybody, I need your help, There is a compatibility issue between IntelliJ and Groovy 5. You can read about the issue here: youtrack.jetbrains.com/issue/IDEA-386167. Please vote so that the IntelliJ team will prioritize it.

Hey folks - I'm trying to implement a client for a RESTful API based on

<http://groovyx.net|groovyx.net>.http.RESTClient

. Is there some guidance for matching some of the config patterns (combo closure+dictionary support, etc.) seen with

get()

,

post()

,

request()

, and so on?

I could possibly derive from RESTClient and override the different methods, but that feels overkill/unwise - the thing I'm trying to solve w/ encapsulation is: • avoiding path-traversal (i.e. can't navigate the client outside of the API base URL) • nuance atop the REST layer (e.g. pagination)

@Sean Williams Have you looked at the declarative http client in groovy 6?

To my knowledge, we're not on Groovy 6 and upgrading isn't within our control (this is in Scriptrunner for Jira - they're the ones shipping groovy classes into the JRE)

Gradle would like to request a backport of the ASM 9.10.1 bump to Groovy 4, so we can support Java 27 in full: https://issues.apache.org/jira/browse/GROOVY-12167

If you are attending Beer City Code this year, please come to my talk Prototype to Production: Finding Flow on the JVM with Groovy and provide your support and feedback. https://www.beercitycode.com/