FizzBuzz with Groovy and Emojis

FizzBuzz is the little interview chestnut: print the numbers 1 to n, but say Fizz for multiples of three, Buzz for multiples of five, and FizzBuzz for multiples of both. It is small enough to fit in a tweet and yet — as a decade of blog posts attests — roomy enough to show off whatever language feature you happen to be fond of this week.

This post is unapologetically in that spirit. It is not a hunt for the one true FizzBuzz; it is a tour of several genuinely different ways to write it in Groovy 6, each with its own flavour. To keep them comparable we render them all with the same emoji instead of words:

The emoji idea is borrowed, with thanks, from Don Raab’s Ternary, Predicate, and Pattern Matching for FizzBuzz with Java 26, which dresses up its Java variants the same way. It is also where the emoji appear in the groovy-verify project, one of whose examples we revisit below.

The starting point for this post was a reader’s first attempt, which already shows how compact Groovy can be:

Every runnable example maps the same range (1..20) and asserts the same canonical output, so the shapes are directly comparable:

A companion project at groovy-fizzbuzz holds runnable versions of every example, resolving Groovy 6.0.0-SNAPSHOT from the ASF snapshot repository.

Groovy’s switch is an expression, and its case labels can be closures used as predicates — applied to the switch subject, first match wins. This is the cleaned-up form of the opening attempt, and the same shape the GPars meets Virtual Threads post used for the word version:

The most concise of Don Raab’s Java variants is a nested ternary, and it translates to Groovy almost character for character. It reads top to bottom — 15, then 3, then 5 — as one expression with no statements:

This particular spelling earns its keep later: it is exactly the spec(n) the verified version proves correct.

Here is a trick that drops the % 15 special case entirely. Glue the 🥤 and 🐝 fragments together; when a fragment doesn’t apply it contributes the empty string and simply vanishes. The FizzBuzz case falls out for free when both are present. Groovy’s Elvis operator (?:) then supplies the number whenever the glued string is empty (and therefore falsy):

Three rules expressed with two tests — the third emerges from the other two.

The well-travelled Reddit thread on the most elegant implementation of FizzBuzz makes a lovely observation: you don’t need a divisibility test in the mapping at all. The 🥤 pattern repeats with period three and the 🐝 pattern with period five; lay them down by position and glue them. The classic Haskell rendition zips two infinite lazy cycles:

That yields the fizz/buzz fragments, but a blank wherever a plain number belongs. The full FizzBuzz zips those against the naturals [1..], keeping the number whenever the glued string is empty:

Indexing two short period arrays by (n - 1) % period is the same idea without the laziness, and it is this second form that Groovy matches — the Elvis ?: n.toString() does the job of if null s then show n:

Arithmetic has moved out of the conditionals and into the indexing — the divisibility is encoded in the lengths of the two patterns.

Groovy 6 can also do the actually lazy version, and now the match with that second Haskell form is almost line for line: repeat() is cycle, zip is the inner zipWith (++), indexed(1) supplies the [1..], collecting is the outer zipWith, and s[0] + s[1] ?: n is the combine that keeps the number when the glue is empty. Nothing is computed until take(20) pulls a prefix:

Same trick, now genuinely infinite — the two streams cycle without end and we simply stop pulling after twenty.

Step back and FizzBuzz is just a function of two yes/no questions — "divisible by three?" and "divisible by five?" — which makes it a function of two bits, and a function of two bits fits in a 2×2 table. The most literal encoding of the problem there is: index the table by those two answers.

Where cycles indexed by position in a period, this indexes by the two conditions — the same data laid out along different axes. The top-left cell is empty, so Elvis supplies the number, exactly as before.

The same table reads naturally as a switch, too. Groovy matches a String case label by equality, so stringifying the pair of bits gives the four rows something concrete to match:

The .toString() is the tell: switch wants a value to compare, so we hand it a string key. Groovy 7 will let us match the structure itself — we come back to that at the end.

Don Raab’s most readable variant uses Eclipse Collections' CaseFunction: an ordered list of (predicate, result) cases, first match wins, with a default. The same idea in plain Groovy is a list of pairs — the cases become data you can build, pass around and extend by appending rather than by editing a switch:

GINQ (Groovy-Integrated Query) gives FizzBuzz a SQL-shaped spelling with from … select …. It is gloriously over-engineered for a problem this small, but it is a genuinely different paradigm — and it would scale to filtering, grouping and joins if the query grew:

FizzBuzz is embarrassingly parallel: each element depends only on its own number, so the work splits cleanly. The earlier GPars post ran the parallel version on the GPars library; in Groovy 6 those patterns are integrated into the core (GEP-18). ParallelScope.withPool(Pool.virtual()) binds a virtual-thread pool for the scope, and collectParallel is the parallel collect:

This borrows the framing from the Concurrency "lite" section of groovy-verify: factor a concurrent computation into a structural guarantee the runtime provides and a local obligation you must get right. Here the structural half is "an order-preserving parallel map gives the same result as the sequential one" — collectParallel keeps encounter order — so all that is left is the per-element mapping. The mapping is unchanged from the sequential versions, which is the whole point: the fizzbuzz closure drops straight in.

That same mapping drops just as easily into ordinary Java Streams — the form Don Raab uses — where switching to parallel is a one-word change:

If parallel FizzBuzz is "get the per-element mapping right and the structure takes care of the rest", it is fair to ask: can we prove we got that element right? The groovy-verify project — an SMT-backed @TypeChecked extension that discharges groovy.contracts annotations at compile time — does exactly that, in the Dafny style of element-wise array verification. A pure spec(n) (the nested ternary from earlier), a loop that fills r[i] = spec(i + 1), and a postcondition saying every slot matches it:

FizzBuzz counts from 1, so the 0-based slot i holds the value for number i + 1 — that + 1 is the bridge between the array index and the FizzBuzz number. The module compiles only because the solver can prove no slot holds the wrong emoji. Introduce the classic off-by-one — r[i] = spec(i) — and the loop invariant is no longer preserved; compilation fails with a concrete counterexample naming the offending slot:

Slot 0 would hold spec(0) == "🥤🐝" (zero divides everything, so it’s FizzBuzz) where number 1 requires "1". "Correct" here means faithful to `spec`: the loop provably realises it at every index, with no gap, overwrite or off-by-one. It doesn’t claim the spec itself is the One True FizzBuzz.

The last two sections each told half a story. The parallel version leaned on a structural guarantee (an order-preserving parallel map) so it only had to get the per-element mapping right; the verified version proved a per-element mapping right. What happens when we put them together — and need to combine the parallel results rather than just collect them?

When the parallel version assembles its per-number tokens, the combine step is the most natural operation in FizzBuzz: gluing the rendered emoji strings together. String concatenation is a monoid — associative, with the empty string as identity — and that associativity is exactly what a parallel reduction relies on: partition the range, render each chunk, recombine, and the result must not depend on where the splits fell. Groovy 6 ships CombinerChecker (from the functional-programming post) to check that algebraic shape; groovy-verify proves the semantics. Turning on both checkers over one class is a genuine two-checker compile:

The two checkers keep their error channels separate but reinforce each other — shape beside semantics:

In fact, those explicit associative and identity methods are more teaching aid than requirement: groovy-verify derives both laws from @Reducer itself, so the combiner alone carries the proof —

The synergy cuts both ways. A non-associative inline combiner like injectParallel(0) { a, b → a - b } is a CombinerChecker error from static shape analysis alone. A method falsely annotated @Associative is trusted by CombinerChecker — but refuted by the verifier, which cannot prove the law holds. And the proof is genuine, not skipped: concatenation is associative but not commutative, and claiming otherwise is rejected with a minimal emoji witness:

That is, "🥤" + "A" ≠ "A" + "🥤". One checker reasons about the syntactic shape, the other about the values; the combiner has to satisfy both.

Stand the two verified sections side by side and the parallel FizzBuzz is correct end to end: every element is proven faithful to spec (the array build), and the combine step is a proven monoid (this Join), so the parallel join is guaranteed to equal the sequential one for any split. The runtime supplies the parallelism; the compiler supplies the proof that using it changes nothing.

And the proof isn’t tied to Groovy’s parallel collections. The JDK’s own Stream.reduce(identity, accumulator) documents that, for correct parallel results, the identity must be a genuine identity and the accumulator must be associative — exactly the monoid contract we just proved. So the same glue drops straight into the ordinary-streams form from earlier, fanned out:

Don Raab’s Java 26 version finally gets primitive patterns — the payoff of a ten-year wait:

Groovy didn’t have to wait. Its standard answer is the closure-case switch from the very first example — available since long before that ten-year clock started ticking, and running unchanged on every currently supported JDK:

What does wait on Groovy 7 is the exact match of Java’s spelling — a primitive type pattern int i that binds and narrows within the case body and its when guard. GEP-19 (Structural Pattern Matching in switch) sketches it, aligning Groovy’s surface syntax with Java’s pattern-matching trajectory:

GEP-19 also brings list patterns — and here is the promised payoff for that stringified-key switch in the truth-table section. Instead of comparing [true, true] as text, you destructure the two remainders and match on the structure directly; the .toString() disappears:

Two details follow from GEP-19’s own disambiguation rule: the wildcard is var (a bare stays an ordinary identifier), and an all-constant label like [0, 0] keeps its legacy isCase meaning — so the both-zero row earns its binding-and-guard rather than matching a constant pair directly.

To be clear, both speculative forms are just that — GEP-19 is a draft targeting Groovy 7 and is not implemented today, so neither compiles on Groovy 6; they live in the companion repo (kept out of the build) only to show where the alignment leads. The point is the contrast: the capability has been there for years and on every JDK; GEP-19 brings the matching syntax, not the power.

One Groovy capability hasn’t appeared yet: runtime metaprogramming — reshaping a type through its metaclass, and overloading operators by name. It’s a real power tool, and the engine behind much of Groovy’s DSL and builder support. FizzBuzz is far too small to need any of it, which makes it a fun way to see how far the language will bend — with the usual caveat that these are tools to reach for deliberately, where they earn their keep.

ExpandoMetaClass can add a property to a type, so every Integer answers for itself:

Now 7.fizzBuzz == 7 and 15.fizzBuzz == '🥤🐝' — the numbers answer for themselves. Tidy, bearing in mind it mutates a JDK type’s metaclass for the whole runtime, which is the kind of reach worth weighing first.

Operators are methods too, so multiply can take a new argument type. Teach Integer a multiply(String) and (it % 3) * '🥤' becomes meaningful — it yields the emoji exactly when the remainder is zero:

And if you would rather not metaprogram at all, the same idea sits in plain arithmetic: '🥤' * n repeats the string n times, so a 0/1 multiplier does the selecting:

All three live in the companion repo’s diabolical/ module. They are a romp at the expressive end of Groovy; in real code the metaclass techniques earn their place in DSLs and frameworks rather than a five-line kata. Powerful when you need them — reach for them when they pull their weight, and leave them be when a plain function will do.

None of these is the way to write FizzBuzz, and that was never the goal. The fun is in how many shapes the same three rules can take: a switch of predicates, a nested ternary, a string you build and let collapse, two periodic patterns you index — or lazily zip forever — a 2×2 truth table you index or switch on, a list of cases as data, a SQL-shaped query, the same mapping fanned across virtual threads, a version a solver proves correct before it ever runs, and a few that bend Groovy’s metaprogramming to the task. Pick the one that makes you smile — and add emoji. 😀