Re: Adding an @Immutable annotation to Java

[Brian Goetz]

I don’t see how a restricted reference by itself is useful, if you cannot 
depend upon the object not being mutated via other references.

Agree; this may help you do local proofs of correctness, and may conceivably 
help the JIT (though, its pretty smart about figuring this stuff out on its 
own), but the benefit doesn’t rise to the level of the complexity here.

The main value of an @Immutable designation is that it is safe to share a 
reference without additional coordination (both sharing with untrusted code, 
and sharing across threads).  But, this is only useful if the designation is 
(a) true all the way down, and (b) cannot be subverted by unsafe casts.

One needs look no farther than String to realize the near-hopelessness of this 
task.  A String is logically immutable, but its representation includes (a) a 
mutable cache of its hashCode, and (b) a reference to a mutable array of bytes 
or chars.  Even if we were willing to throw (a) overboard, (b) would require 
some sort of @TrustMe, which we could conceivably do for jl.String, but 
couldn’t possibly expose more broadly without driving the value of the 
mechanism to near-zero.  Treat this as an existence proof that mutability is 
just too pervasive to contain, at least for now.

There are efforts underway to chip away at some of the untamed mutability; 
frozen arrays are on the drawing board (addressing (b)), and Valhalla will join 
records in defining _shallowly_ immutable aggregates.  (It could conceivably go 
farther, but not until we can at least bring String into the fold.)  But we’d 
need to make a lot more progress before anyone could consider believing an 
@Immutable designation.  And if it can’t be believed, it doesn’t have enough 
value to put in the language.  (No problem with privately using annotations to 
capture design intent in documentation, but the bar for the language is higher 
than that.)

There are other impediments too; much ink has been spilled on the challenges of 
capturing immutability in a type hierarchy as complex as Collections.  But my 
main point is that while this is something that initially seems desirable, when 
you start pulling on the string, you realize it is not as useful as it 
initially seems in an environment of pervasive mutability.

Re: Adding an @Immutable annotation to Java

[Alan Snyder]

> On Nov 29, 2021, at 10:42 AM, Simon Roberts  
> wrote:
> 
> I will say that as Java provides more and more features modeled on more
> functional languages, I'm finding more and more people struggling with the
> inherently mutable nature of Java, and that I strongly believe that
> something that helps bridge the gap is likely to be crucial to the
> language's continued improvement and growth. Clearly it can't turn into
> Haskell, nor should it, but without saying what, may I add my voice to
> those looking for this kind of feature.
> 

I agree with this sentiment.

> One thing that I haven't seen discussed is the fact that Java has had the
> "const" keyword since the beginning, but it's never been implemented. That
> raises the question of whether it's more practical (in terms of bridging
> styles) for methods to guarantee that they don't change some object (i.e.
> implement const) or for a data type to be declared in a way that it cannot
> be mutated (i.e. the @Immutable discussion). Given the difficulties raised
> already in attempts to create truly immutable lists, or perhaps read-only
> lists, and merge them in the existing library APIs, perhaps it's worth
> considering attacking the problem from the other side? Perhaps there's a
> way to declare a particular reference as "only to be used with const /
> non-mutating operations". Might the combination of those two features be
> worth consideration?

I don’t see how a restricted reference by itself is useful, if you cannot 
depend upon the object not being mutated via other references.
Swift has solved this issue (as far as I can tell), but it has a fundamentally 
different semantics.

I think the solution is to abandon the goal of fully integrating immutable 
collections into the existing collections API.
Yes, that creates API bloat, but it may be worth it.
I’ve done that in my own programming and have no regrets.

There are precedents: NIO Paths vs Files, Streams vs Iterators, Modules vs 
Classpaths.
To be fair, I don’t use Paths or Streams or Modules, because the payoff seems 
small.
The payoff for immutable collections is much larger, in my opinion (less buggy 
code).

  Alan

Re: Adding an @Immutable annotation to Java

[Simon Roberts]

I will say that as Java provides more and more features modeled on more
functional languages, I'm finding more and more people struggling with the
inherently mutable nature of Java, and that I strongly believe that
something that helps bridge the gap is likely to be crucial to the
language's continued improvement and growth. Clearly it can't turn into
Haskell, nor should it, but without saying what, may I add my voice to
those looking for this kind of feature.

One thing that I haven't seen discussed is the fact that Java has had the
"const" keyword since the beginning, but it's never been implemented. That
raises the question of whether it's more practical (in terms of bridging
styles) for methods to guarantee that they don't change some object (i.e.
implement const) or for a data type to be declared in a way that it cannot
be mutated (i.e. the @Immutable discussion). Given the difficulties raised
already in attempts to create truly immutable lists, or perhaps read-only
lists, and merge them in the existing library APIs, perhaps it's worth
considering attacking the problem from the other side? Perhaps there's a
way to declare a particular reference as "only to be used with const /
non-mutating operations". Might the combination of those two features be
worth consideration?

Cheers,
Simon


On Mon, Nov 29, 2021 at 11:06 AM Alberto Otero Rodríguez <
albest...@hotmail.com> wrote:

> I have created myself a project with a possible implementation of
> Immutable Collections using the source code of Java 17.
>
> https://github.com/Aliuken/JavaImmutableCollections
> [
> https://opengraph.githubassets.com/b1aeb5022614cc86e9ca7b0effe8a6298ce1ba62fee0b97021af3ff40e505cea/Aliuken/JavaImmutableCollections
> ]<https://github.com/Aliuken/JavaImmutableCollections>
> GitHub - Aliuken/JavaImmutableCollections<
> https://github.com/Aliuken/JavaImmutableCollections>
> Contribute to Aliuken/JavaImmutableCollections development by creating an
> account on GitHub.
> github.com
>
> 
> De: Alberto Otero Rodríguez 
> Enviado: jueves, 25 de noviembre de 2021 9:39
> Para: Justin Dekeyser 
> Cc: core-libs-dev@openjdk.java.net 
> Asunto: RE: Adding an @Immutable annotation to Java
>
> I have not thought about that. I'm not a Java expert.
>
> I just throwed the idea precisely to avoid "fake immutability", because a
> programmer could think one record is immutable simply by being a record,
> while this is false.
>
> There are probably lots of problems that need to be taken in consideration
> (like inheritance). But I just throw the idea because I think it would be a
> desirable feature.
>
> I would be grateful if some expert could deepen in possible problems and
> their solutions.
>
> Regards,
>
> Alberto Otero Rodríguez.
> ________
> De: Justin Dekeyser 
> Enviado: jueves, 25 de noviembre de 2021 9:27
> Para: Alberto Otero Rodríguez 
> Cc: core-libs-dev@openjdk.java.net 
> Asunto: Re: Adding an @Immutable annotation to Java
>
> Hello,
>
> Quick question, out of curiosity: how would it behave with respect to
> inheritance? Can a @Immutable class inherit from an non immutable one?
> if no: that's a bit annoying, no? (fake immutability)
> Can @Immutable class be subclassed to a non @Immutable one? if no:
> that's a bit annoying too, no? (downcasting)
>
> Since Object is the super class of everything, it sounds like a
> problem. What have you thought about to handle this concern?
>
> Regards,
>
> Justin Dekeyser
>
> On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez
>  wrote:
> >
> > Hi, I was thinking that it could be interesting adding an @Immutable
> annotation to Java. It would be a marker annotation for the compiler
> (similar to @FunctionalInterface) in order to throw an error if the
> annotated class/record has a component that is not @Immutable.
> >
> > This means that all existing immutable objects (like the
> primitive-wrapping objects and String) should be annotated with @Immutable
> and the programmer could, for example, annotate a new record object with
> @Immutable only if all its fields are annotated with @Immutable.
> >
> > What do you think?
> >
> > Regards,
> >
> > Alberto Otero Rodríguez.
>


-- 
Simon Roberts
(303) 249 3613

RE: Adding an @Immutable annotation to Java

[Alberto Otero Rodríguez]

I have created myself a project with a possible implementation of Immutable 
Collections using the source code of Java 17.

https://github.com/Aliuken/JavaImmutableCollections
[https://opengraph.githubassets.com/b1aeb5022614cc86e9ca7b0effe8a6298ce1ba62fee0b97021af3ff40e505cea/Aliuken/JavaImmutableCollections]<https://github.com/Aliuken/JavaImmutableCollections>
GitHub - 
Aliuken/JavaImmutableCollections<https://github.com/Aliuken/JavaImmutableCollections>
Contribute to Aliuken/JavaImmutableCollections development by creating an 
account on GitHub.
github.com


De: Alberto Otero Rodríguez 
Enviado: jueves, 25 de noviembre de 2021 9:39
Para: Justin Dekeyser 
Cc: core-libs-dev@openjdk.java.net 
Asunto: RE: Adding an @Immutable annotation to Java

I have not thought about that. I'm not a Java expert.

I just throwed the idea precisely to avoid "fake immutability", because a 
programmer could think one record is immutable simply by being a record, while 
this is false.

There are probably lots of problems that need to be taken in consideration 
(like inheritance). But I just throw the idea because I think it would be a 
desirable feature.

I would be grateful if some expert could deepen in possible problems and their 
solutions.

Regards,

Alberto Otero Rodríguez.

De: Justin Dekeyser 
Enviado: jueves, 25 de noviembre de 2021 9:27
Para: Alberto Otero Rodríguez 
Cc: core-libs-dev@openjdk.java.net 
Asunto: Re: Adding an @Immutable annotation to Java

Hello,

Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?
if no: that's a bit annoying, no? (fake immutability)
Can @Immutable class be subclassed to a non @Immutable one? if no:
that's a bit annoying too, no? (downcasting)

Since Object is the super class of everything, it sounds like a
problem. What have you thought about to handle this concern?

Regards,

Justin Dekeyser

On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez
 wrote:
>
> Hi, I was thinking that it could be interesting adding an @Immutable 
> annotation to Java. It would be a marker annotation for the compiler (similar 
> to @FunctionalInterface) in order to throw an error if the annotated 
> class/record has a component that is not @Immutable.
>
> This means that all existing immutable objects (like the primitive-wrapping 
> objects and String) should be annotated with @Immutable and the programmer 
> could, for example, annotate a new record object with @Immutable only if all 
> its fields are annotated with @Immutable.
>
> What do you think?
>
> Regards,
>
> Alberto Otero Rodríguez.

Re: Adding an @Immutable annotation to Java

[Rob Spoor]

If this is really something that's desired, then why use an annotation 
when there's a keyword already available: const. However, there's a 
reason that's never been actually used in Java, and that's because it's 
so hard to get right.



On 26/11/2021 00:11, Alan Snyder wrote:

I like the idea of an @Immutable annotation. So much so, that I have created 
one and use it heavily.
However, my @Immutable is just for documentation; it does not have a rigorous 
semantics that would be
needed for a compiler to validate its use or generate different code.
But it could be used by lint-like tools to warn against suspicious code.

My @Immutable applies only to classes and interfaces, not variables or type 
parameters.
A class or interface is either @Immutable or it is not.
That avoids much complexity.

I think it is fine to have an @Immutable list (type) whose elements are mutable.
Is an instance of an immutable list with mutable elements immutable or not?
Tell me why you want to know and I might be able to answer the question.

I also think there are cases where an @Immutable type might have a mutable 
implementation
(in other words, it might have instance variables that are not final or have 
non-immutable types).
Examples include internal caching and configurability of performance or 
incidental behavior such as logging.

In general, immutability is in the mind of the beholder.

A case can be made that an interface or class that is @Immutable should only 
permit
extensions and implementing classes that are @Immutable.
Perhaps a compiler could validate that, but only at compilation time
(to ensure binary compatibility when an @Immutable annotation is added to an 
existing class or interface).

The idea of the compiler trying to enforce a semantics of immutability is scary.
Java tried to do this with uninitialized and final instance variables, and the 
result has been a disaster.
The rules make semantically valid code illegal, forcing complex workarounds.
(For example, suppose you want to compute a value, bind it to a final instance 
variable, and pass it to the superclass constructor.)
Yet it is still possible, actually quite easy, to write code that accesses 
uninitialized final variables.
I have code that checks a final @NotNull instance variable to ensure that it is 
not null.
IDEA tells me the check is unnecessary, but IDEA is wrong.

Immutability is a much more complicated concept than uninitialized.
Not something the compiler should mess with.

   Alan




On Nov 25, 2021, at 10:10 AM, Ralph Goers  wrote:

I would think that if a class is marked immutable that would imply all the 
fields in it and from its inherited
classes should be immutable. If fields are marked immutable then it would only 
apply to them.

What I wonder is what its relationship to final would be. The final annotation 
implies that a field must be
set in the constructor and cannot be modified after that. I would imagine that 
@immutable to have to imply
@final but would also apply at runtime. For example, where declaring a List 
field as final means you cannot
replace the List once it is set. I would expect @Immutable to do the same but 
also mean that you cannot
add elements to the List through that reference. But that would also mean that 
you cannot pass the reference
to another variable that isn’t also annotated with @Immutable - unless the 
immutable attribute becomes some
kind of internal flag on the object.

To be clear, this concept is always something I have wanted in Java. It is a 
real pain to have to do things like
List list = Collections.unmodifiableList(List.of(“foo”, “bar”));

Instead, it would be nice to be able to do
@Immutable List list = List.of(“foo”, “bar”);

Although the two could be implemented to do the same thing, the second could 
prevent passing the field in a
parameter that wasn’t declared @Immutable. Likewise, passing a non-immutable 
list in a parameter annotated
with @Immutable could cause the list to be copied to an immutable list 
automatically.

Ralph


On Nov 25, 2021, at 2:49 AM, Mariell Hoversholm  
wrote:

On Thu, 25 Nov 2021 at 10:03, Andrew Haley 
wrote:


Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?


And: does @Immutable mean deeply immutable? IMO it really should,
but that's harder to check, and we'd have to think about what this
means for binary compatibility.



As cited in the original email,

and the programmer could, for example, annotate a new record object with

@Immutable only if all its fields are annotated with @Immutable.

I would infer from this that it would mean deeply immutable.
To clarify further, the following record `Wrapper` would be legal only
because `A` has `@Immutable` on its _type_:

   @Immutable class A {}
   @Immutable record Wrapper(A a) {}

while this would not be legal:

   class A {}
   @Immutable record Wrapper(A a) {}

because `A` is not `@Immutable`. This could 

Re: Adding an @Immutable annotation to Java

[Alan Snyder]

I like the idea of an @Immutable annotation. So much so, that I have created 
one and use it heavily.
However, my @Immutable is just for documentation; it does not have a rigorous 
semantics that would be
needed for a compiler to validate its use or generate different code.
But it could be used by lint-like tools to warn against suspicious code.

My @Immutable applies only to classes and interfaces, not variables or type 
parameters.
A class or interface is either @Immutable or it is not.
That avoids much complexity.

I think it is fine to have an @Immutable list (type) whose elements are mutable.
Is an instance of an immutable list with mutable elements immutable or not?
Tell me why you want to know and I might be able to answer the question.

I also think there are cases where an @Immutable type might have a mutable 
implementation
(in other words, it might have instance variables that are not final or have 
non-immutable types).
Examples include internal caching and configurability of performance or 
incidental behavior such as logging.

In general, immutability is in the mind of the beholder.

A case can be made that an interface or class that is @Immutable should only 
permit
extensions and implementing classes that are @Immutable.
Perhaps a compiler could validate that, but only at compilation time
(to ensure binary compatibility when an @Immutable annotation is added to an 
existing class or interface).

The idea of the compiler trying to enforce a semantics of immutability is scary.
Java tried to do this with uninitialized and final instance variables, and the 
result has been a disaster.
The rules make semantically valid code illegal, forcing complex workarounds.
(For example, suppose you want to compute a value, bind it to a final instance 
variable, and pass it to the superclass constructor.)
Yet it is still possible, actually quite easy, to write code that accesses 
uninitialized final variables.
I have code that checks a final @NotNull instance variable to ensure that it is 
not null.
IDEA tells me the check is unnecessary, but IDEA is wrong.

Immutability is a much more complicated concept than uninitialized.
Not something the compiler should mess with.

  Alan



> On Nov 25, 2021, at 10:10 AM, Ralph Goers  wrote:
> 
> I would think that if a class is marked immutable that would imply all the 
> fields in it and from its inherited 
> classes should be immutable. If fields are marked immutable then it would 
> only apply to them.
> 
> What I wonder is what its relationship to final would be. The final 
> annotation implies that a field must be 
> set in the constructor and cannot be modified after that. I would imagine 
> that @immutable to have to imply 
> @final but would also apply at runtime. For example, where declaring a List 
> field as final means you cannot 
> replace the List once it is set. I would expect @Immutable to do the same but 
> also mean that you cannot 
> add elements to the List through that reference. But that would also mean 
> that you cannot pass the reference 
> to another variable that isn’t also annotated with @Immutable - unless the 
> immutable attribute becomes some 
> kind of internal flag on the object.
> 
> To be clear, this concept is always something I have wanted in Java. It is a 
> real pain to have to do things like
> List list = Collections.unmodifiableList(List.of(“foo”, “bar”));
> 
> Instead, it would be nice to be able to do
> @Immutable List list = List.of(“foo”, “bar”);
> 
> Although the two could be implemented to do the same thing, the second could 
> prevent passing the field in a 
> parameter that wasn’t declared @Immutable. Likewise, passing a non-immutable 
> list in a parameter annotated 
> with @Immutable could cause the list to be copied to an immutable list 
> automatically.
> 
> Ralph
> 
>> On Nov 25, 2021, at 2:49 AM, Mariell Hoversholm  
>> wrote:
>> 
>> On Thu, 25 Nov 2021 at 10:03, Andrew Haley 
>> wrote:
>> 
 Quick question, out of curiosity: how would it behave with respect to
 inheritance? Can a @Immutable class inherit from an non immutable one?
>>> 
>>> And: does @Immutable mean deeply immutable? IMO it really should,
>>> but that's harder to check, and we'd have to think about what this
>>> means for binary compatibility.
>>> 
>> 
>> As cited in the original email,
>>> and the programmer could, for example, annotate a new record object with
>> @Immutable only if all its fields are annotated with @Immutable.
>> 
>> I would infer from this that it would mean deeply immutable.
>> To clarify further, the following record `Wrapper` would be legal only
>> because `A` has `@Immutable` on its _type_:
>> 
>>   @Immutable class A {}
>>   @Immutable record Wrapper(A a) {}
>> 
>> while this would not be legal:
>> 
>>   class A {}
>>   @Immutable record Wrapper(A a) {}
>> 
>> because `A` is not `@Immutable`. This could however borrow from the Rust
>> concept of "auto-traits" (read: automatically apply certain traits or
>> 

Re: Adding an @Immutable annotation to Java

[Ralph Goers]

I would think that if a class is marked immutable that would imply all the 
fields in it and from its inherited 
classes should be immutable. If fields are marked immutable then it would only 
apply to them.

What I wonder is what its relationship to final would be. The final annotation 
implies that a field must be 
set in the constructor and cannot be modified after that. I would imagine that 
@immutable to have to imply 
@final but would also apply at runtime. For example, where declaring a List 
field as final means you cannot 
replace the List once it is set. I would expect @Immutable to do the same but 
also mean that you cannot 
add elements to the List through that reference. But that would also mean that 
you cannot pass the reference 
to another variable that isn’t also annotated with @Immutable - unless the 
immutable attribute becomes some 
kind of internal flag on the object.

To be clear, this concept is always something I have wanted in Java. It is a 
real pain to have to do things like
List list = Collections.unmodifiableList(List.of(“foo”, “bar”));

Instead, it would be nice to be able to do
@Immutable List list = List.of(“foo”, “bar”);

Although the two could be implemented to do the same thing, the second could 
prevent passing the field in a 
parameter that wasn’t declared @Immutable. Likewise, passing a non-immutable 
list in a parameter annotated 
with @Immutable could cause the list to be copied to an immutable list 
automatically.

Ralph

> On Nov 25, 2021, at 2:49 AM, Mariell Hoversholm  
> wrote:
> 
> On Thu, 25 Nov 2021 at 10:03, Andrew Haley 
> wrote:
> 
>>> Quick question, out of curiosity: how would it behave with respect to
>>> inheritance? Can a @Immutable class inherit from an non immutable one?
>> 
>> And: does @Immutable mean deeply immutable? IMO it really should,
>> but that's harder to check, and we'd have to think about what this
>> means for binary compatibility.
>> 
> 
> As cited in the original email,
>> and the programmer could, for example, annotate a new record object with
> @Immutable only if all its fields are annotated with @Immutable.
> 
> I would infer from this that it would mean deeply immutable.
> To clarify further, the following record `Wrapper` would be legal only
> because `A` has `@Immutable` on its _type_:
> 
>@Immutable class A {}
>@Immutable record Wrapper(A a) {}
> 
> while this would not be legal:
> 
>class A {}
>@Immutable record Wrapper(A a) {}
> 
> because `A` is not `@Immutable`. This could however borrow from the Rust
> concept of "auto-traits" (read: automatically apply certain traits or
> capabilities depending on how the type is defined), and infer `@Immutable`
> if it is deeply immutable, but that would raise the question of API &
> binary compatibility again.
> 
> It would also not be legal with this:
> 
>@Immutable
>class A {
>private int value;
>public void value(int value) { this.value = value; }
>}
> 
> because `value` is _not_ immutable.
> 
> Moving on from your question, this then poses the question of memoizing
> potentially very expensive optimisations, such as the following, currently
> found in the JDK:
> https://github.com/openjdk/jdk/blob/f0136ec94539d0e30ec11d44f8143196da1f7125/src/java.base/share/classes/java/lang/String.java#L2323-L2343
> Code above from `java.base/java.lang.String`:
> 
>public int hashCode() {
>// [snip large comment]
>int h = hash; // [hash is a property on the type]
>if (h == 0 && !hashIsZero) { // [hashIsZero is a property on the
> type]
>h = isLatin1() ? StringLatin1.hashCode(value)
>   : StringUTF16.hashCode(value);
>if (h == 0) {
>hashIsZero = true;
>} else {
>hash = h;
>}
>}
>return h;
>}
> 
> If the compiler / JRE were to infer the immutability from setters, it would
> again pose a new question of how to detect such. It could be possible that
> adding a new keyword or annotation to ignore mutable fields would be
> necessary (say `private mutable int hashCode;` as an example of my
> thoughts). At that point, however, what is the difference to not having
> this feature at all?
> 
> This is definitely an idea I like as a user of the language, but it's
> something that would require a bit of work, assuming it can be boiled down
> to something feasible at all.
> 
> -- 
> 
> *Mariell Hoversholm *(she/her)
> 
> Software Developer @ 
> 

Re: Adding an @Immutable annotation to Java

[Andrew Haley]

On 11/25/21 08:27, Justin Dekeyser wrote:



Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?


And: does @Immutable mean deeply immutable? IMO it really should,
but that's harder to check, and we'd have to think about what this
means for binary compatibility.

On 11/25/21 08:39, Alberto Otero Rodríguez wrote:
> I have not thought about that. I'm not a Java expert.
>
> I just throwed the idea precisely to avoid "fake immutability", because a 
programmer could think one record is immutable simply by being a record, while this is false.
>
> There are probably lots of problems that need to be taken in consideration 
(like inheritance). But I just throw the idea because I think it would be a 
desirable feature.
>
> I would be grateful if some expert could deepen in possible problems and 
their solutions.

Everything is always harder than it looks at first.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: Adding an @Immutable annotation to Java

[Alberto Otero Rodríguez]

I have not thought about that. I'm not a Java expert.

I just throwed the idea precisely to avoid "fake immutability", because a 
programmer could think one record is immutable simply by being a record, while 
this is false.

There are probably lots of problems that need to be taken in consideration 
(like inheritance). But I just throw the idea because I think it would be a 
desirable feature.

I would be grateful if some expert could deepen in possible problems and their 
solutions.

Regards,

Alberto Otero Rodríguez.

De: Justin Dekeyser 
Enviado: jueves, 25 de noviembre de 2021 9:27
Para: Alberto Otero Rodríguez 
Cc: core-libs-dev@openjdk.java.net 
Asunto: Re: Adding an @Immutable annotation to Java

Hello,

Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?
if no: that's a bit annoying, no? (fake immutability)
Can @Immutable class be subclassed to a non @Immutable one? if no:
that's a bit annoying too, no? (downcasting)

Since Object is the super class of everything, it sounds like a
problem. What have you thought about to handle this concern?

Regards,

Justin Dekeyser

On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez
 wrote:
>
> Hi, I was thinking that it could be interesting adding an @Immutable 
> annotation to Java. It would be a marker annotation for the compiler (similar 
> to @FunctionalInterface) in order to throw an error if the annotated 
> class/record has a component that is not @Immutable.
>
> This means that all existing immutable objects (like the primitive-wrapping 
> objects and String) should be annotated with @Immutable and the programmer 
> could, for example, annotate a new record object with @Immutable only if all 
> its fields are annotated with @Immutable.
>
> What do you think?
>
> Regards,
>
> Alberto Otero Rodríguez.

Re: Adding an @Immutable annotation to Java

[Justin Dekeyser]

Hello,

Quick question, out of curiosity: how would it behave with respect to
inheritance? Can a @Immutable class inherit from an non immutable one?
if no: that's a bit annoying, no? (fake immutability)
Can @Immutable class be subclassed to a non @Immutable one? if no:
that's a bit annoying too, no? (downcasting)

Since Object is the super class of everything, it sounds like a
problem. What have you thought about to handle this concern?

Regards,

Justin Dekeyser

On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez
 wrote:
>
> Hi, I was thinking that it could be interesting adding an @Immutable 
> annotation to Java. It would be a marker annotation for the compiler (similar 
> to @FunctionalInterface) in order to throw an error if the annotated 
> class/record has a component that is not @Immutable.
>
> This means that all existing immutable objects (like the primitive-wrapping 
> objects and String) should be annotated with @Immutable and the programmer 
> could, for example, annotate a new record object with @Immutable only if all 
> its fields are annotated with @Immutable.
>
> What do you think?
>
> Regards,
>
> Alberto Otero Rodríguez.