Amber features 2026

Wed Jan 14 19:50:36 UTC 2026

> From: "Tagir Valeev" <amaembo at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Gavin Bierman" <gavin.bierman at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, January 14, 2026 7:49:38 PM
> Subject: Re: Amber features 2026

> Hi, Remi!

Hello Tagir, 

> Not mentioning the type name at the use site will greatly reduce IDE performance
> for find usages functionality. Imagine, one wants to find the uses of a
> particular record component. Now, we can use identifier index to quickly find
> all the files that mention the record name, and perform more detailed search on
> this much smaller subset of files. In your proposed syntax, (var a, var b) =
> foo().bar() is completely opaque. To understand which record is used here, we
> need to perform full resolve and type inference for foo() and bar(), which may
> depend on content of other source files, so we cannot use only content of the
> current file as a cache dependency.

Is it different from 
var a = foo().bar().getA(); 
var b = foo().bar().getB(); 

which works like a charm in IntelliJ. 

That said, I curently do not use 'var' in record patterns because IDEs (not IntelliJ) tend to miss those type references. 

> We already have a huge problem when searching for functional interface
> implementations (i.e. all the lambdas and method references that implement it).
> The functional interface is usually not mentioned explicitly near the lambda,
> so such a search is extremely slow on big projects.

In IntelliJ, you can add a lambda symbol in the gutter part of the editor, it will give you the functional interface. 

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 | 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 < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>>> From: "Gavin Bierman" < [ mailto:gavin.bierman at oracle.com |
>> > gavin.bierman at oracle.com ] >
>>> To: "amber-spec-experts" < [ mailto:amber-spec-experts at openjdk.java.net |
>> > 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/cfa903b0/attachment.htm>