Writing immutable objects in Java is hard, there is already a check list: - be sure that your class in not only unmodifiable but really immutable, storing a mutable class in a field is an issue - do you have declared all fields final, otherwise you have a publication issue - your constructors do not leak "this", right !
so adding a forth item - the class is not a primitive class does not seem to be a big leap too me. This whole area seems extremely prone to wishful thinking; we hate the idea of making something slower than it could be, that we convince ourselves that “the user can reason about this.” Whether or not it is “too big a leap”, I think it is a bigger leap than you are thinking. For me, we should make the model clear, the compiler should insert a non user overridable default constructor but not more because using a primitive class is already an arcane construct. This might help a little bit, but it is addressing the smaller part of the problem (zeroes); we need to address the bigger problem (tearing). I don’t think we have to go so far as to outlaw tearing, but there have to be enough cues, at the use and declaration site, that something interesting is happening here. There is no point to nanny people here given that only experts will want to play with it. This is *definitely* wishful thinking. People will hear that this is a tool for performance; 99% of Java developers will convince themselves they are experts because, performance! Developers pathologically over-rotate towards whatever the Stack Overflow crowd says is faster. (And so will Copilot.) So, definitely no. This argument is pure wishful thinking. (I will admit to being occasionally tempted by this argument too, but then I snap out of it.) But we (the EG) can also fail, and make a primitive class too easy to use, what scare me is people using primitive class just because it's not nullable. Yes, this is one of the many pitfalls we have to avoid! This game is hard.
