Hi Gianluca,
I agree:
1. I would say people copy & paste from Java, since there is so much
code out there /and/ since Groovy (I think rightly so) has always
tried very hard to stay syntax compatible with it.
2. Kotlin is imho too different for one keyword to make much of a
difference - just think e.g. of its JavaScript-style postfix type
syntax - and JetBrains offers only Groovy-to-Kotlin autoconversion
in IntelliJ, for obvious reasons.
3. Scala uses the same type syntax, is less popular, as well as more
functional than Groovy, so there is even less argument to be made
here to have a small copy & paste compatibility.
Cheers,
mg
Am 14.04.2026 um 09:52 schrieb Gianluca Sartori:
> It's a convenience to have some more copy/pasting friendliness with
languages that adopted val.
Is this a real case? Do people copy paste from Java/Scala/Kotlin into
a Groovy file/project?
Also, raising the topic to a philosophical layer, sometimes adding
features dilutes the concepts.
I'd rather prefer to have a strong language with few concepts and its
own identity.
When we want to please anyone, we end up pleasing no one.
I also believe we should start thinking about a Groovy version in the
future (like version 10 for instance) where we make breaking changes
to consolidate the language (like Python has done in version 3).
Breaking changes are painful, risky and always too much work, but as
with any other software the issue is "when" not "if".
Mantra of the day:
To add is simple,
to remove is complicated.
Sorry if this sounds a bit critical, my intention is to be helpful.
Gianluca Sartori
--
https://dueuno.com
On Tue, 14 Apr 2026 at 08:32, Guillaume Laforge <[email protected]>
wrote:
We also have var although we had def.
It's a convenience to have some more copy/pasting friendliness
with languages that adopted val.
On Tue, Apr 14, 2026 at 12:30 AM MG <[email protected]> wrote:
Hi Caleb,
my main argument is that one does not need "val", if already
existing "final" would do the same thing, i.e. do RHS type
inference (see also "To add to my initial arguments" in my
reply to Christopher Smith).
Cheers,
mg
PS: To comment on some of your points:
1. One does not always have the luxury of using an IDE when
looking at Groovy code.
2. A simple syntax highlighting editor (if that is available)
might struggle with separating "val" the keyword from
"val" the variable/field name (one of the many reasons why
I think "val" is such a bad choice).
3. @any declaration that takes multiple words: True for most
ppl, full agreement, but we can use existing single word
"final" keyword (or, if necessary, introduce a better one
than "val"), as in final x = new Foo().
4. @value-based semantics never having been a thing in any
JVM languages: It is in Groovy, see @Immutable* (which
GEP-16 explicitly states of being a non-goal of
introducing a "val" keyword).
*https://docs.groovy-lang.org/latest/html/gapi/groovy/transform/Immutable.html
Am 13.04.2026 um 02:23 schrieb Caleb:
MG,
A note on "val" looking similar to "var": any good IDE labels
final and non-final variables differently, e.g. IJ uses an
underline. Even vim does this afaik. The keywords look
similar in isolation, sure, but everywhere besides the
declaration, you're not looking at the keyword for that
info. And with the underline on the variable, the
declarations don't look similar at all from experience. I've
never been confused in Kotlin, even coming from Java where
var was the only similar keyword.
Plus, from my experience, any declaration that takes multiple
words to communicate it (even something as small as "let
mut") just feels clunky compared to "val" and "var". It
doesn't feel good to use, as it takes up more space in your
brain trying to read it.
You're also intuitively dissuaded from using the more
complicated one because it takes an extra word, so if "final"
is the extra word and it's not necessary to basic operation,
very few people will use it. (See: Java, C, C++, literally
every single language where "final" is the "second word".)
On the topic of val meaning value-based semantics: that's
never been a thing in any JVM languages, and val isn't used
as a keyword in the major languages where it does exist.
(Namely C, C++, and Rust.)
Cheers,
Caleb
On Sun, Apr 12, 2026, 6:35 PM MG <[email protected]> wrote:
Hi Paul,
I still have the following gripes with using "val" (and
two other languages having imho made a bad choice here
still does not change that :-) ):
1. "val" for me indicates value- (as opposed to
reference) based semantics, i.e. copy semantics /
deep immutabilty, which the proposal explictly states
is not the goal here (see Non-goals @Immutable in the
GEP).
2. "val" looks a lot like "var".
1. So if looking over code it is harder to spot an
error in this regard
2. And it might be confusing for ppl new to Groovy
(unless they come from Kotlin or Scala, which I
find unlikely to happen).
3. "val" is a variable name ppl use (Contrary to final,
def and var).
1. While this would still work , e.g. "val val" just
looks akward.
2. As well as making code using "val" as a variable
name generally worse to read.
4. I see no need for "val", when it seems the same
effect could be reached by changing the semantics of
existing "final" to use RHS type deduction*.
1. It seems to me this would not be a breaking
change... (?)
5. So while having type deduction would help our
framework quite a bit, I would argue for:
1. "final" to finally be type deducing* G-)
2. Or at least for a different keyword to be used.
1. It is late and I need to go to sleep, but
from the top of my head: "fvar" or "fin"
1. ("fin" would hit two birds with one
stone: shorten the quite long "final" and
supply type deduction).
Cheers,
mg
*straightforward & stable, i.e. 99% what the user expects
- make the frequent case easy/fast, make the rare case
correct (i.e. require the developer to supply an explicit
type).
Am 12.04.2026 um 13:59 schrieb Paul King:
Hi folks,
We have been asked numerous times about the possibility
of having a "val" keyword to match Kotlin and Scala. We
also have had a related Jira open for more than 6
years. So I created a GEP to help frame a discussion
about what would be involved and help us make a decision:
https://groovy.apache.org/wiki/GEP-16.html
I know we have "final", but many developers I speak to
from the Kotlin and Scala worlds are big fans of "val"
and believe it was the right name to use for those two
languages.
Given that it involves changes to only about 15 lines of
production Groovy code and has well-identified impacts
(arguably edge cases with workarounds), I am largely in
favor of this proposal, but I am keen to hear other's
thoughts.
Cheers, Paul.
--
*Guillaume Laforge*
Apache Groovy committer*
*
Developer Advocate @ Google Cloud <https://cloud.google.com/>
* Blog: glaforge.dev <http://glaforge.dev/>
* X: @glaforge <http://twitter.com/glaforge>
* Bluesky: @glaforge.dev <https://bsky.app/profile/glaforge.dev>
* Mastodon: @[email protected] <http://%[email protected]/>
