<div dir="auto">One idea could be to make the class declaration special. In well structured classes all fields should live at the top so having a class modifier like "immutable" would be rather obvious even with lots of fields. Also rather a field declared at line 20 and used in line 650 is mutable already requires scrolling to the top. <div dir="auto"><div dir="auto"><br></div><div dir="auto">On that note the editor/ide is a more often used indicator for mutablity of fields by having color or styling differences in the variable name. (I know relying on tooling to make things clear is not preferable but it's kinda already this way)</div><div dir="auto"><br></div><div dir="auto">An example class would look similar to this :</div><div dir="auto"><br></div><div dir="auto">public immutable class Test {</div><div dir="auto">private int field1;</div><div dir="auto">private int field2;</div><div dir="auto">private int field3;<br></div><div dir="auto">private int field4;<br></div><div dir="auto">private int field5;<br></div><div dir="auto">private int field6;</div><div dir="auto">private int field7;</div><div dir="auto">private int field8;</div><div dir="auto">private mutable int field9;</div><div dir="auto">private mutable int field10;</div><div dir="auto">}</div><div dir="auto"><br></div><div dir="auto">Rather to combine default final and default private is another discussion. </div><div dir="auto"><br></div><div dir="auto">A counter argument would be that allowing for any combination of defaults would result in a keyword explosion:</div><div dir="auto">immutable </div><div dir="auto">mutable </div><div dir="auto">closed (wip to make a class private default) </div><div dir="auto">package-private</div><div dir="auto"><br></div><div dir="auto">Just to allow inverting the defaults. </div><div dir="auto"><br></div><div dir="auto">Also c# already has this for immutable fields. They have the readonly keyword which is equivalent to final on fields in java but it also works on the class making every field readonly. The problem with that approach in java is that we already used final on classes to block inheritance.</div><div dir="auto"><br></div><div dir="auto">Maybe we could instead drop the inversion (package-private and mutable) and make it a 1 way decision like in records. But then the question would be why not just use a record. </div><div dir="auto"><br></div><div dir="auto">That are my thoughts on this topic. As one might have heard out I'm undecided on the topic.</div><div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 18, 2024, 17:56 Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<font size="4" face="monospace">So, you provide several good
arguments here for "Java picked a bad default with respect to
mutability." (It is in good company; Java picked many bad
defaults, such as package visibility rather than private, classes
being extensible rather than closed, etc.) Let's just take it as
given that non-final is an imperfect default for fields. <br>
<br>
Which brings us to the next question: "now that we realize the
default is bad, should we change it?" This is a much harder
question, because it involves the reality of 10M developers and
billions of lines of code. <br>
<br>
One bit of prior art here that might be relevant (and the
experiment is still playing out) is C#'s flipping of the
nullability default on a per-module basis (with injecting checking
at the boundaries.) This was a bold experiment and we are
interested in seeing the results.<br>
<br>
The problem with trying to fix the mistakes of the past is that in
most cases, you are just creating a fork and forcing users to deal
with both branches. If we had a directive:<br>
<br>
class X { <br>
#pragma default-final<br>
<br>
...<br>
}<br>
<br>
then now users have to keep track (possibly on a per-file basis)
of where "int x" means final or mutable. This is adding cognitive
load to all users, since almost no Java developer has the luxury
of controlling 100% of the code they deal with. <br>
<br>
<blockquote type="cite">
<div>A one line distillation of the above is perhaps:
"Immutability is common enough to consider a fast path at
source level; the current slow path has negative consequences
for cognition and devx."</div>
</blockquote>
<br>
Valid, but what this misses is: "having to constantly reason about
whether line #656 of Moo.java is on the fast path or the slow path
has even higher cognitive load." <br>
<br>
</font><br>
<div>On 1/17/2024 10:20 PM, Subra V wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello Project Amber team,
<div><br>
</div>
<div>What are the current thoughts on providing source level
mechanisms for opting-in to mutability rather than the current
opt-out? For example, a notion of immutable class (not a
record) can obviate specifying "private final" for fields.
Opt-in mutability would perhaps also jive with two recent
themes in language evolution: 1. Functional style 2. More
cognition, less ceremony (switch statement, pattern matching
to name a few). </div>
<div><br>
</div>
<div>If there's prior relevant material, I'd appreciate a
pointer; Dr. Google hasn't uncovered anything of note.
<div><br>
</div>
<div>I realize that this question has red flags of "proposing
a solution" to "my specific problem". So, let me clarify
that (1) I only write because I believe there's a reasonable
chance that opt-in mutability is of fairly broad interest.
(2) I am not proposing obviating the need for 'private
final' as a solution; instead, it is meant to be analogous
to saying 'I want String interpolation', a 'solution' from
which language designers carefully teased apart a
general problem and solved it in the form of String
Templates.
<div>---</div>
<div><br>
</div>
<div>I am certain language designers are aware of this (and
plenty more), but in the interest of intellectual honesty,
let me attempt to articulate problems with
default-mutability from my default-immutable practice.</div>
<div><br>
</div>
<div>1. [Immutable style feels second class] Java has moved
in a functional direction much to my (and most
practitioner's?) pleasure. For the subset of folks who buy
into this direction, Immutable classes are natural. Yet,
they feel second class in that (1) notions of "private
final" aren't relevant yet pollute (2) It requires extra
work [making all fields final, binding them in
constructor] compared to the default case of mutability</div>
<div><br>
</div>
<div>2. [Cognitive Cost of Ceremony] For non-record
Immutable classes, I have to (1) Write 'private final X'
and then add a constructor param and set `this.X = X` in
the constructor. (2) Read and verify `private final` on
every field to know that the class is immutable. Even
though IDEs help, it breaks the flow of thought both when
reading and writing</div>
<div><br>
</div>
<div>3. [Poor Prototyping Velocity] I often find the
ceremony especially frustrating in early phases of design,
especially when using immutable classes. Imagine I have 20
concepts/fields and I am attempting to organize them. A
common occurrence is to realize 'ohh this field/method
logically belongs to that other class; let me move it
there' but it is a pretty big chore to do so (even with
Intellij) given that immutability takes extra work to
achieve. Such moves also come with further transitive
ripple effects. All the busy work perhaps accounts for
upwards of 30% of the initial few hours/days of design and
more importantly, constantly interrupts thoughts. For
contrast, if I just make every field public during the
initial period, it'd probably be a better experience, but
then I need a magic wand to make them all immutable after
the design settles down.</div>
<div><br>
</div>
<div>A one line distillation of the above is perhaps:
"Immutability is common enough to consider a fast path at
source level; the current slow path has negative
consequences for cognition and devx."</div>
<div><br>
</div>
<div>Appreciate thoughts.</div>
<div><br>
</div>
<div>Thank you,</div>
<div>Subrahmanyam</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div>