for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

John Rose john.r.rose at
Sat Mar 7 23:18:30 UTC 2020

On Mar 7, 2020, at 2:22 PM, forax at wrote:
> Marker interface are usually problematic because:
> - they can inherited, for inline classes, you can put them on our new kind of abstract class, which will make things just harder to diagnose.

As always the flexibility of inheritance cuts both ways.
Suppose I define AbstractSlice with subtypes MemorySlice,
ArraySlice, etc. and I intend it for secure applications.
I then mark AbstractSlice as NonTearable, and all its subs
are therefore also NonTearable.  You cannot do that with
an ad hoc keyword, even if you want to.  You have to make
sure that every concrete subtype mentions the keyword.

It’s a trade-off, of course, but for me the cost of a new keyword
pushes me towards using types making the property inherited.
It’s a decision which falls squarely in the center of the language.

> - they can be uses as a type, like Serializable is used where it should not.
>  By example, what an array of java.lang.NonTearable means exactly. There is a potential for a lot of confusion. 

Again, if I have an algorithm that works for a range of value
types (via an interface or abstract super), I can express the
requirement that the inputs to the algorithm be non-tearable,
using subtypes.  For example, the bound (Record & NonTearable)
expresses and enforces the intention that the algorithm will
operate on non-tearable record values.

> and in the specific case of NonTerable, a non inline class can implement it, again creating confusion.

The confusion comes from the incomplete story here.  I’d like to
suggest that IdentityObject implements NonTearable, so that
bounds like Record & NonTearable allow identity and inline

— John

More information about the valhalla-spec-observers mailing list