> 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]/>
