- "AlwaysAtomic"
- John: "bitwise atomic", non-tearability, across the the inline-type
- No concerns over what is intended, nope
- In keeping with >= JDK9 JMM
- Brian: declaration where by you can't accidentally forget use
site, blanket behavior to be absolutely sure
- John: "spelling" "bit-wise atomic", so even as keyword
- Marker interface might be a better way to go as alternative to
keyword
- Prototyping might consider annotation
- Remi: prefers the type
- Fred: Arrays, we can't declare with modifiers, in the same way
- Could use Foo.ref[] to guarantee
- Wrapper auto-boxing...something we could explore...
- Remi/Brian: "non-tearable" might be better
- John: but Doug's comment about MM terminology
- Brian: but MM EGs are not users
- John: "java.lang.NonTearable" seem like the way to go
- Brian: Dan's proposal on using abstract classes
- Quick look at current java.base abstract classes, most are
"well-behavior"
- Suggestion that the abstract constructor would signal usefulness
- What if we use ValueBased marker interface on the abstract class
- Are there too many rules for the user ? This might be hard to explain
- Banning fields, constructor, synchronized
- John: intention to prototype specialization using constant pool "holes"
- in particular descriptors
- Remi: question wildcards ?
- Brian:
- we have learned we use erasure as a bound, and don't need
special wildcard
- Array co-variant subtyping needed for this to work
- Tobi: question on withfield (and ordering of final fields) do we
consider that a constructor
- John: Yes, needs to be added to the JMM note on constructors
(note on "freeze operation")
