Amber features 2026
Tagir Valeev
amaembo at gmail.com
Wed Jan 14 21:05:21 UTC 2026
Hi!
On Wed, Jan 14, 2026, 20:50 <forax at univ-mlv.fr> wrote
> Is it different from
> var a = foo().bar().getA();
> var b = foo().bar().getB();
>
> which works like a charm in IntelliJ.
>
Here, if you search for getA invocation, you can query the identifier index
for 'getA', which is mentioned. If you want to search for the type of a,
then this location will not be found, because the type is not mentioned.
Find usages is crucial for refactorings. If you rename the type, you don't
need to find this location, because the type is not mentioned. However, if
you reorder record components, you have to find all the deconstructions to
update them as well, even if the record is not mentioned. Similarly, if you
change the signature of functional interface SAM, you have to update all
the lambdas, so you have to find them.
> That said, I curently do not use 'var' in record patterns because IDEs
> (not IntelliJ) tend to miss those type references.
>
> In IntelliJ, you can add a lambda symbol in the gutter part of the editor,
> it will give you the functional interface.
>
Going from lambda to its functional interface is much simpler than the
opposite task of finding all the lambdas in the project that implement this
interface. While it's still a nontrivial type inference problem, it should
be performed at a single location, not at thousands of possible locations
all over the project.
> So yes, relying on type inference makes compilers slower and the IDEs
> slower, and reconciling indexes is a PITA,
> but suppressing redundant information in the code, for example
> (var x, var y) = foo.getPoint();
>
> also helps readability (see
> https://openjdk.org/projects/amber/guides/lvti-style-guide)
>
>
> With best regards,
> Tagir Valeev
>
>
> regards,
> Rémi
>
>
> On Wed, Jan 14, 2026, 19:17 Remi Forax <forax at univ-mlv.fr> wrote:
>
>> ----- Original Message -----
>> > From: "Gavin Bierman" <gavin.bierman at oracle.com>
>> > To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> > Sent: Saturday, January 10, 2026 12:08:05 AM
>> > Subject: Amber features 2026
>>
>> > Dear spec experts,
>> >
>> > Happy New Year to you all! We thought this was a good time to share you
>> some of
>> > the thinking regarding Amber features for 2026.
>> >
>> > Currently we have one feature in preview - Primitive Patterns. We’d
>> love to get
>> > more feedback on this feature - please keep kicking the tires!
>> >
>> > We plan two new features in the near term. Draft JEPs are being worked
>> on and
>> > will be released as soon as possible. But here are some brief details
>> while you
>> > are waiting for the draft JEPs (in the name of efficiency, *please*
>> let's save
>> > discussion for that point).
>> >
>> > ## PATTERN ASSIGNMENT
>> >
>> > Pattern matching is an inherently partial process: a value either
>> matches a
>> > pattern, or it does not. But sometimes, we know that the pattern will
>> always
>> > match; and we are using the pattern matching process as a convenient
>> means to
>> > disassemble a value, for example:
>> >
>> > record ColorPoint(int x, int y, RGB color) {}
>> >
>> > void somethingImportant(ColorPoint cp) {
>> > if (cp instanceof ColorPoint(var x, var y, var c)) {
>> > // important code
>> > }
>> > }
>> >
>> > The use of pattern matching is great, but the fact that we have to use
>> it in a
>> > conditional statement is annoying. It’s clutter, and worse, it is making
>> > something known by the developer and compiler look as if it were
>> unknown; and,
>> > as a consequence, the important code ends up being indented and the
>> scope of
>> > the pattern variables is limited to the then block. The indent-adverse
>> > developer may reach for the following, but it’s hardly better:
>> >
>> > void somethingImportant(ColorPoint cp) {
>> > if (!(cp instanceof ColorPoint(var x, var y, var c))) {
>> > return;
>> > }
>> > // important code
>> > }
>> >
>> > The real issue here is that both the developer and the compiler can see
>> that the
>> > pattern matching is not partial - it will always succeed - but we have
>> no way
>> > of recording this semantic information.
>> >
>> > What we really want is a form of assignment where the left-hand-side is
>> not a
>> > variable but a **pattern**. So, we can rewrite our method as follows:
>> >
>> > void somethingImportant(ColorPoint cp) {
>> > ColorPoint(var x, var y, var c) = cp; // Pattern Assignment!
>> > // important code
>> > }
>> >
>> > Luckily, the spec already defines what it means for a pattern to be
>> > unconditional (JLS 14.30.3), so we can build on this
>> >
>> > void hopeful(Object o) {
>> > ColorPoint(var x, var y, var c) = o; // Compile-time error!
>> > }
>> >
>> >
>>
>> Doing the advent of code of last December, I miss that feature :)
>>
>> But I'm still ambivalent about that feature, for me, it looks like we are
>> missing the big picture.
>>
>>
>> Every time i've talked about this feature in JUGs, one of the questions
>> was why do we need to indicate the type given that the compiler knows it.
>> For example
>>
>> void hopeful(ColorPoint cp) {
>> (var x, var y, var c) = cp;
>>
>> // instead of
>>
>> ColorPoint(var x, var y, var c) = cp;
>> }
>>
>>
>> I wonder if the general question hidden behind is why is it a pattern
>> assignment and not a de-structuration like in other languages.
>>
>> Let's take another example, in other languages, one can write swap like
>> this
>> int a = ...
>> int b = ...
>> (b, a) = (a, b);
>>
>> The equivalent would be
>>
>> record Pair(int first, int second) {}
>> int a = ...
>> int b = ...
>> Pair(var x, var y) = new Pair(a, b);
>> a = x;
>> b = y;
>>
>> Or should we support assignment without the creation of new bindings ?
>>
>> record Pair(int first, int second) {}
>> int a = ...
>> int b = ...
>> Pair(b, a) = new Pair(a, b);
>>
>> Or maybe, this feature should be named pattern declaration and not
>> pattern assignment ?
>>
>>
>> For me, this feature is about de-structuring assignment but by seeing
>> through the keyhole of patterns, i'm fearing we are missing the big picture
>> here.
>>
>> regards,
>> Rémi
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20260114/44fb322b/attachment.htm>
More information about the amber-spec-experts
mailing list