records. If the first line is a call to another ctor, then how can you set a field on that line also

[Anil Philip]

Boyarsky-Selikoff Sybex829 Ch 7 page 380

I don't understand what this means. If the first line is a call to another ctor, then how can you set a field on that line also?

you can only transform the data on the first line. After the first line, all of the fields will already be assigned

from

The first line of an overloaded constructor must be an explicit call to another constructor via this(). If there are no other constructors, the long constructor must be called. Contrast this with what you learned about in Chapter 6, where calling super() or this() was often optional in constructor declarations. Also, unlike compact constructors, you can only transform the data on the first line. After the first line, all of the fields will already be assigned, and the object is immutable.

public record Crane(int numberEggs, String name) {
    public Crane(int numberEggs, String firstName, String lastName) {
        this(numberEggs + 1, firstName + " " + lastName);
        this.numberEggs = 20; // DOES NOT COMPILE
    }
}

[Ira Go]

I found it confusing too.
The first line means the call to another constructor. So whatever needs to be done to the parameters, it must happen when the other constructor is called. The chain of constructors will end up with the canonical constructor and the record's data will be set final at that point. When you return from the call to the other constructor, the fields will be set and will be final/immutable. So you can't do anything after the call to that constructor which happened on the first line.

[Campbell Ritchie]

Please avoid abbreviations like “ctor” which can confuse people; Google translate can't understand it.

IG has told you, fields in a record are implicitly final, and your line 4 is trying to assign a final variable twice. I suggest you go through the JLS about records and see what it says about multiple constructors. What Boyarsky and Selikoff wrote is by no means clear, but the only way to avoid double assignments is to restrict all constructors but one to calling this(...); and nothing else. Mutable classes allow assignments to follow this(...); and you doubtless already know why you mustn't omit assigning of any fields in every record constructor.

[Anil Philip]

Ira Go wrote:I found it confusing too.
The first line means the call to another constructor. So whatever needs to be done to the parameters, it must happen when the other constructor is called. The chain of constructors will end up with the canonical constructor and the record's data will be set final at that point. When you return from the call to the other constructor, the fields will be set and will be final/immutable. So you can't do anything after the call to that constructor which happened on the first line.

Then you might as well have just one compact constructor!

[Anil Philip]

Campbell Ritchie wrote:Please avoid abbreviations like “ctor” ...
IG has told you,

Haha you used an abbreviation here

[Mike Simmons]

Anil Philip wrote:If the first line is a call to another ctor, then how can you set a field on that line also?

you can only transform the data on the first line. After the first line, all of the fields will already be assigned

That call to the other constructor is how the fields are being set.  Running the other constructor sets the fields.

But while the first line must be a call to another constructor, there are nonetheless ways to insert some transformation of the data before the constructor is called.  You show one yourself:

public record Crane(int numberEggs, String name) { 
  public Crane(int numberEggs, String firstName, String lastName) {
    this(numberEggs + 1, firstName + " " + lastName);
  }
}

Here the first line of the Crane(int, String) constructor is an invocation of the canonical constructor - and yet, it is changing the data on the way.  It's replacing numberEggs with numberEggs + 1.  And it's putting firstName and lastName together into a single name, separated by " ".  Those are both transformations of data, made by inserting simple expressions into the constructor invocation.  You could also insert an arbitrarily complex expression into that first line - but at some point, it's better to create a new static method, and insert that instead:

public record Crane(int numberEggs, String name) {
  public Crane(int numberEggs, String firstName, String lastName) {
    this(fixNumberEggs(numberEggs), makeName(firstName, lastName));
  }
  
  private static int fixNumberEggs(int num) {
    if (num < 0) {
      num = 0;
    }
    // Cranes are superstitious and want to only have an even number of eggs
    if (num % 2 == 1) {
      num -= 1;
    }
    return num;
  }
  
  private static String makeName(String firstName, String lastName) {
    if (firstName == null) {
      firstName = "";
    }
    if (lastName == null) {
      lastName = "";
    }
    firstName = firstName.trim();
    lastName = lastName.trim();
    if (firstName.isBlank()) {
      return lastName;
    }
    if (lastName.isBlank()) {
      return firstName;
    }
    return firstName + " " + lastName;
  }
}

So you can squeeze quite a bit of transformation into that one line, if you need to.  Note that you aren't allowed to invoke an instance method there, or a this reference, because the current instance isn't fully constructed yet.  But you can do a lot of other things with the constructor parameters.

Anil Philip wrote:Then you might as well have just one compact constructor!

A compact constructor is a more flexible way to handle this sort of initialization.  But you can only have one compact constructor, and it is a direct companion to the one canonical constructor - that is, you can only reference variables from the canonical constructor arguments, and the canonical constructor is implicitly called at the end of the compact constructor.  The point being, all of this is of no help if you want to be able to create a constructor with a different list of arguments.  For that you need an overloaded constructor, by definition.  And that's when you have to deal with the no-data-alteration-except-on-first-line rule.

Note that they are finding ways to relax these rules in future versions of Java, starting with JDK 22.  But for now, these are the rules we must deal with.