Ok, so back to my question: what is the purpose of binding an immutable Java field with an immutable type to an updateable column?

Assuming we go with the mutability/updateability split, then an example of the mapping you are asking about would be what I posted above:

@Immutable
String name;

We have an immutable type (String). Here, the @Immutable is unnecessary - it's already immutable. And it is updateable. I mean that's perfectly valid, fairly normal mapping right?

Hibernate ORM will never update it, right?

And no, the column here does get updated; it is not mapped as non-updateable. That would look like either of these:

@Column(updatable=false)
String name;

or

@Updateable(false)
String name;

it's already immutable. And it is updateable. I mean that's perfectly valid, fairly normal mapping right?

I'm sorry but no, I don't think that makes much sense. And I still don't see the purpose of that.

To me either a property is (deeply) immutable and then there's no reason for it to be updateable, or it's mutable at least at some level, and then yes, sure, it makes sense for it to be updateable.

But deeply immutable (hence never updated) and updateable... No, I don't understand how that's useful.

Well I think you are still missing the point of mutability. Maybe I'm wrong though.

@Entity class TheEntity {
 ...
 String name;
 Date start;
 @Immutable
 Date end;
}

name is immutable - we cannot change it's internal state. But obviously nothing stops us from changing the attribute:

TheEntity theEntity = ...;
theEntity.setName( "the new name" );

This clearly triggers an update (its updateable).

start, as a Date is mutable - therefore there are 2 ways to trigger dirtiness:

TheEntity theEntity = ...;
theEntity.setStart( ... );

and

TheEntity theEntity = ...;
theEntity.getStart().setTime( ... );

As stated numerous times, because it is mutable we have to use .equals to check dirtiness and we have to create a deep copy when creating the TheEntity state array and when interacting with L2 cache.

end, as as Date, is normally mutable. However, here we have explicitly told Hibernate to treat it as immutable. This has a few impacts centered on the fact the we will ignore any internal state change. So while this dirties the entity:

TheEntity theEntity = ...;
theEntity.setEnd( ... );

this does not:

TheEntity theEntity = ...;
theEntity.getEnd().setTime( ... );

The important implication really is that we can skip the deep copies, generally speaking.

But deeply immutable (hence never updated) and updateable... No, I don't understand how that's useful.

Right, because (I think) you keep confusing mutable and updateable.

name is immutable - we cannot change it's internal state. But obviously nothing stops us from changing the attribute:

Ok, that's probably the source of the misunderstanding.

Then my objection would be that the meaning you assign to @Immutable is confusing, at least to me. I'd expect this:

 @Immutable
 Date end;

... to mean that the end field won't be mutated (but the value it holds still can, that's unrelated). Because, well, I just annotated a field with @Immutable, so that field is not mutable, right?

With that meaning, a similar field of type String could be considered non-updateable automatically.

Now I guess if your @Immutable annotation is annotated with something like @java.lang.annotation.Target({ElementType.TYPE_USE}), usage and meaning would be consistent: in the example above, the annotation would apply to Date, not to Date end. But that's still confusing as hell; probably even more so.

"Do you have anything constructive to suggest instead of wasting my time", you'll say, and you'll be right.

I suppose @MutabilityOverride would make sense in this context, and, while verbose, would at least suggest a similar behavior to @AttributeOverride/@AssociationOverride which affects the type of the attribute rather than the attribute itself. And (at least in the example above) there's no way to interpret this as affecting the field itself, since where would be the override then?

I suppose @MutabilityOverride would make sense in this context

We already have @Mutability to allow users to plug in custom "mutability overrides".

Then my objection would be that the meaning you assign to @immutable is confusing

I don't think it really is though. So long as the meaning is consistent regardless of the placement, that is an easy thing to communicate - @Immutable == "immutable internal state". And it is also consistent with @Mutability.

Also, the meaning you ascribe to @Immutable is just not at all what it has meant for its entire existence. 6.2 added the ability to apply @Immutable on attributes whereas previously that was not allowed. As part of that work, when @Immutable is used on a @Basic attribute, it also added this additional non-updateable semantic. In my opinion, that introduced an inconsistency in the message - the meaning of "immutable" was no longer the same depending on where it was used.

Yeah, I'm fine with the concept of a @Final annotation as a shorthand for @Column(updatable = false).

If we don't update a column, then mutability is irrelevant to Hibernate. We will never copy a value or compare values for dirtiness.

OK, so you're arguing that @Updatable(false) or @Final imply @Mutability(Immutability.class). Perfect! You agree with my point!

Since we don't make use of the mutability plan when the column is not updatable, I guess that it doesn't matter what we do with the mutability plan then, but sure, forcing the immutable mutability plan works for me.

we don't make use of the mutability plan when the column is not updatable

I mean, that's an optimization / implementation detail I don't care about at all. What I care about is the user-visible semantics, which it seems we agree on.

I said from the very beginning that this is all about (1) consistency and (2) unfortunate term overload.

Great, fine. I'll just drop my PR and we can live with the inconsistency and constantly explain how this works.

BTW, @Immutable-on-attribute was never documented. Would be nice if that happened.

For example, Steve didn’t like that my impl of @Immutable on fields didn’t do anything about mutability plans. But of course it didn’t need to because snapshotting/dirty-checking are already implicitly bypassed!

OMG this shit is so confusing!