On October 6, 2021 10:07:09 AM UTC, Maurizio Cimadamore
<maurizio.cimadam...@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é.
