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 <justin.dekeyser@gmail.com> Enviado: jueves, 25 de noviembre de 2021 9:27 Para: Alberto Otero Rodríguez <albest512@hotmail.com> Cc: core-libs-dev@openjdk.java.net <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 <albest512@hotmail.com> 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.

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 < albest512@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/b1aeb5022614cc86e9ca7b0effe8a6298ce1ba62f... ]<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 <albest512@hotmail.com> Enviado: jueves, 25 de noviembre de 2021 9:39 Para: Justin Dekeyser <justin.dekeyser@gmail.com> Cc: core-libs-dev@openjdk.java.net <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 <justin.dekeyser@gmail.com> Enviado: jueves, 25 de noviembre de 2021 9:27 Para: Alberto Otero Rodríguez <albest512@hotmail.com> Cc: core-libs-dev@openjdk.java.net <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 <albest512@hotmail.com> 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

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.

On Thu, 25 Nov 2021 at 10:03, Andrew Haley <aph-open@littlepinkcloud.com> 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... 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 @ <https://aboutpaf.com>

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 <ralph.goers@dslextreme.com> 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<String> 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 <mariell.hoversholm@paf.com> wrote:

On Thu, 25 Nov 2021 at 10:03, Andrew Haley <aph-open@littlepinkcloud.com> 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... 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 @ <https://aboutpaf.com>