Component deprecation (was: [records] Record updates for Preview/2)

Tagir Valeev amaembo at
Fri Jan 10 03:17:13 UTC 2020

I can imagine that the record component loses its meaning and now
should be ignored.

E.g. record Point(int x, int y, @Deprecated int z) {} // the budget
was cut, so we are building 2D game now instead of 3D.

In this case, to make it convenient for new call sites while keeping
the old call sites compilable, it would be good to introduce
non-canonical constructor:

record Point(int x, int y, @Deprecated int z) {
  public Point(int x, int y) { this(x, y, 0); }

Probably we can mark a canonical constructor as deprecated if at least
one record component is deprecated because using the canonical
constructor you're essentially using the deprecated component.

However, to me it looks much better to remove component at all in this
case, and emulate it for old call sites:

record Point(int x, int y) {
  @Deprecated public Point(int x, int y, int z) { this(x, y); }
  @Deprecated public int z() { return 0; } // or even throw

This should be source and binary compatible change. The only problem
is the deserialization of old streams (provided the record is

With best regards,
Tagir Valeev.

On Fri, Jan 10, 2020 at 6:42 AM Dan Smith <daniel.smith at> wrote:
> > On Jan 9, 2020, at 10:51 AM, forax at wrote:
> >
> > Currently you can not deprecate a record component unlike in Scala or in Kotlin.
> > We can either allow @Deprecated or pretend that people will never make mistake, change their mind, specification will never change, etc
> Setting aside implementation details, and whether there's any change to be made here: I'm curious about what you intend a deprecated record component to *mean*. How do you deprecate a single parameter of a constructor? A concrete example could be useful—I can believe there might be something there, but I'm struggling to see it.
> A related StackOverflow discussion about deprecated parameters/locals:

More information about the amber-spec-experts mailing list