skip to content

Groovy lets you omit parentheses on method calls in build.gradle. When is this safe and when does it cause ambiguity or errors?

level: middleimportance: should knowfreq 45%

answer

  1. command expression = top-level call, >=1 arg
  2. zero-arg needs () — property vs call
  3. nested/assignment/condition needs ()
  4. apply plugin: 'java' idiom
  5. Kotlin DSL has no paren-omission

basics

~20 s

Groovy allows dropping parentheses on top-level method calls with at least one argument (command chains), like apply plugin: 'java'. It's not allowed for zero-argument calls or when a call is nested inside an expression, where it becomes ambiguous.

solid answer

~50 s

Groovy supports 'command-expression' syntax: a top-level statement that is a method call with one or more arguments may omit parentheses — `apply plugin: 'java'`, `implementation 'g:n:v'`, `from 'src'`. The compiler treats the first token as a method and the rest as its argument(s). Restrictions: you **cannot** omit parens on a **zero-argument** call (`mavenCentral` is a property access, not a call — you need `mavenCentral()`), and you cannot omit them when the call is **not** the top of the statement, e.g. inside an expression, assignment RHS, or as an argument to another call, because Groovy can't tell where one call ends and the next begins. So `version = project.findProperty('v')` needs parens. This is why DSL examples freely drop parens for declarations but keep them for nested/computed calls; over-omitting is a common source of confusing parse errors.

code

groovy · 3 lines
groovy
apply plugin: 'java'              // OK: top-level, one arg
repositories { mavenCentral() }   // mavenCentral() needs () (zero-arg call)
version = project.findProperty('appVersion')  // () required: assignment RHS

go deeper

for a junior

Know the apply plugin: 'java' style and that mavenCentral() needs parentheses.

for a middle

Explain command expressions: top-level + at least one argument; zero-arg and nested calls need parens.

for a senior

Diagnose parse errors caused by paren omission in assignment/condition positions and recommend explicit style for clarity.

for a principal

Set a team style guideline (or migrate to Kotlin DSL) to eliminate ambiguity-class errors across a large build.

## Command expressions Groovy has a special top-level form called a *command expression* (or command chain). At statement position, a method call with **at least one argument** can be written without parentheses and without dots between alternating method/argument pairs: ```groovy apply plugin: 'java' // apply(plugin: 'java') implementation 'g:n:v' // implementation('g:n:v') from 'src/main/resources' // from('src/main/resources') ``` The parser reads `identifier argument` as `identifier(argument)`. Chains like `take 2 from list` are possible but rare in build scripts. ## Where it breaks 1. **Zero-argument calls.** Without an argument, `foo` is parsed as a *property read*, not a call. `mavenCentral` alone tries to read a property named mavenCentral and fails; you must write `mavenCentral()`. That's why repositories blocks always have parens on `mavenCentral()`, `mavenLocal()`. 2. **Non-statement position.** Inside an expression — an assignment RHS, an `if` condition, a method argument, a list element — Groovy requires parentheses because the command-expression grammar only applies at the top of a statement: ```groovy version = project.findProperty('appVersion') // parens required if (file('x').exists()) { } // parens required ``` Writing `version = project.findProperty 'v'` is a parse error. 3. **Ambiguity with multiple tokens.** `tasks.named 'build'` works as a command, but chaining further (`tasks.named 'build' configure {...}`) gets ambiguous fast; explicit parens are clearer. ## Practical rule of thumb - Top-level **declaration** with one argument → parens optional, idiomatic to omit (`apply plugin:`, `implementation '…'`). - **Zero-arg** calls → always need `()`. - Anything **nested, assigned, or conditional** → always use `()`. ## Why it matters Many 'unexpected token' build-script errors trace to dropping parens where the command-expression grammar doesn't apply. Knowing the rule lets you read terse scripts and write unambiguous ones — and it's a frequent reason the same logic must be written more explicitly in Kotlin DSL, which has no command-expression sugar at all.

  • Why does mavenCentral need parentheses but apply plugin: 'java' does not?
    apply has an argument so the command-expression form applies. mavenCentral has no argument, so without () it's parsed as a property read, not a call.
  • Does Kotlin DSL support omitting parentheses like Groovy?
    No. Kotlin requires parentheses on calls (apart from a trailing lambda outside the parens). That's one reason the Kotlin DSL reads more explicitly.

saying these in an interview costs you the question

  • Claiming you can always drop parentheses anywhere in Groovy.
  • Saying zero-argument calls can omit parentheses (they become property reads).

context

resolving links…