Addressing the full range of use cases

[Remi Forax]

On October 6, 2021 10:07:09 AM UTC, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
>On 06/10/2021 10:56, Remi Forax wrote:
>>> - Existing class types like LocalDate are both nullable and atomic. These are
>>> useful properties to preserve during migration; nullability, in particular, is
>>> essential for source compatibility. We've provided reference-default
>>> declarations as a mechanism to make reference types (which have these
>>> properties) the default, with 'P.val' as an opt-in to value types. But in doing
>>> so we take away the many benefits of value types by default, and force new code
>>> to work with the "bad name".
>> The existing class LocalDate is not atomic per se, atomic in Java implies volatile and currently if a LocalDate field is updated in one thread, another thread may never see that update.
>> LocalDate is currently not tearable, a QLocalDate; is tearable in case of racy code.
>
>The fact that QLocalDate is tearable is a consequence of the fact that 
>e.g. elements of a QLocalDate[] cannot be read/written atomically - e.g. 
>in a single shot, unlike for references - which are pointers and can be 
>loaded/stored atomically (as per Java Memory Model).
>
>It's true the word "atomic" is sometimes used to refer to operations 
>such as CAS which provide strong inter-thread guarantees - this is not 
>what Dan had in mind here.

Right, I used to think that being tearable was a huge issue.

Now, I don't.
At least, not to the point of making primive classes non tearable the default.

As I said, the code need to have race issues to  observe that behavior and I think that a security token should not be a primitive class, i.e. i can live with the fact that a user can forge any permutations of my primitive class if he writes racy code on purpose. 

>
>Maurizio
>


Rémi

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.