Amber features 2026

[Remi Forax]

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