From dcrystalmails at gmail.com  Thu Apr  7 22:54:17 2022
From: dcrystalmails at gmail.com (Dimitris Paltatzidis)
Date: Fri, 8 Apr 2022 01:54:17 +0300
Subject: Primitive classes default value javadoc
Message-ID: <CAMg+uVT4ynkAoW9FeqAi4H6c3AFeNDwbfXt4vRniWaKh-b9aCA@mail.gmail.com>

How to document the default value of a Primitive class?

Speculations:
1. Mention in the class doc.
2. Special stuff resulting in a dedicated doc like other fields.
3. Don't. "no one writes or reads docs anyway.. ouch"

To me; 1. seems reasonable, at least for now, even though 2.'s outcome
seems attractive.

From anhmdq at gmail.com  Tue Apr 26 13:32:28 2022
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Tue, 26 Apr 2022 21:32:28 +0800
Subject: About ref-default-ness of primitive classes
Message-ID: <CAPvyiy+ou=uN_FH6AGTumxW9qgz5nQ-rFqfhD2NN0a0A3JNacg@mail.gmail.com>

Hi Valhalla experts,

I really like the idea of making the ref variant to be the alias of the
class name instead of the val variant. Aside from the mentioned ideas, it
always feels a little uncomfortable knowing that value-based classes such
as Optional will forever carry the compatibility baggage and not be able to
fully utilise the benefits of Valhalla. By going this path, contemporary
value-based classes can be migrated directly to B3, which will both improve
the performance of today's programs, and open the door for the future to
fully take advantage of primitive classes.

Regarding the nature to look secondary of the naming, I would propose
primitive classes be able to explicitly declare the name of their value
companions, similar to how int can be declared as the value variant of
Integer. This would remove the magic of basic primitive namings. At this
point, B2 and B3 seem to be almost the same, the final nail would be to
make a class not have the value variant unless it explicitly asks for one.

By the way, I feel that the problem of atomicity is being exaggerated.
Tearing comes from racy code that does not fully understand its
implications. As a result, while it should be taken into consideration, bad
code should not affect our design of Valhalla. And I think it should be
discussed after everything else has settled.

My apologies if these ideas are obvious and/or incorrect.
Regards,
Quan Anh

From romanowski.mateusz at gmail.com  Tue Apr 26 21:18:56 2022
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Tue, 26 Apr 2022 23:18:56 +0200
Subject: We need help to migrate from bucket 1 to 2; and, the == problem
In-Reply-To: <034E48A2-8AB2-4156-A30C-F6F79F8CABC3@oracle.com>
References: <CAGKkBksxR=MiaW4-w_6Lb_gxgZDub0WdLhFZa9aQ-WUEAv1eZQ@mail.gmail.com>
 <38DF0B35-3F89-484F-8A35-FF2F5924859C@oracle.com>
 <CAGKkBkup_kk+t_hJpNE8=gUaP12PS4621aFeZXAuFE5yEtaL2g@mail.gmail.com>
 <034E48A2-8AB2-4156-A30C-F6F79F8CABC3@oracle.com>
Message-ID: <CAL-BTSp6KEoGa8d=FQPQHJKG_8Wg0qwaj3agKSaT=FtEA_nxww@mail.gmail.com>

To Experts,
Regarding migration of value-based classes into bucket 2 value classes,
while keeping callers that are depending on identity (`==` mostly)
unsurprised..

..could adding a pivot field, perhaps _temporarily_, during migration help?

I assume that for following `Preload`ed B2 class..
```
public value class Year {
   private final Object pivot = new Object();
   private final int year;

   public Year(int year) {
     this.year = year;
   }

   // methods
}
```
..instances would be flattened into a reference and `int`,
while keeping `new Year(1999) != new Year(1999)` working.

Regards,
Mateusz Romanowski

On Tue, Apr 26, 2022 at 8:53 PM Dan Smith <daniel.smith at oracle.com> wrote:

> On Apr 26, 2022, at 8:22 AM, Kevin Bourrillion <kevinb at google.com<mailto:
> kevinb at google.com>> wrote:
>
> It's a great start, but the key difference is that we need to be able to
> apply this process to *our own* types, not just the JDK types. Really, we
> should see whatever we need to do for JDK types as a clue to what other
> library owners will need as well.
>
> Yes, a public annotation was the original proposal. At some point we
> scaled that back to just JDK-internal. The discussions were a long time
> ago, but if I remember right the main concern was that a formalized, Java
> SE notion of "value-based class" would lead to some unwanted complexity
> when we eventually get to *real* value classes (e.g., a misguided CS 101
> course question: "what's the difference between a value-based class and a
> value class? which one should you use?"). It seemed like producing some
> special warnings for JDK classes would address the bulk of the problem
> without needing to fall into this trap.
>
> Would an acceptable compromise be for a third-party tool to support its
> own annotations, while also recognizing @jdk.internal.ValueBased as an
> alternative spelling of the same thing?
>
> (Secondarily... why are we warning only on synchronization, and not on
> `==` or (marginal) `identityHC`?)
>
> I think this was simply not a battle that we wanted to fight?discouraging
> all uses of '==' on type Integer, for example.
>
> We spent some time trying to figure out what to say about '==', and came
> up with this:
>
> "the class does not provide any instance creation mechanism that promises
> a unique identity on each method call?in particular, any factory method's
> contract must allow for the possibility that if two independently-produced
> instances are equal according to equals(), they may also be equal according
> to ==;"
>
> and
>
> "When two instances of a value-based class are equal (according to
> `equals`), a program should not attempt to distinguish between their
> identities, whether directly via reference equality or indirectly via an
> appeal to synchronization, identity hashing, serialization, or any other
> identity-sensitive mechanism."
>
> (See
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html
> )
>
> Within these constraints, there are reasonable things that can be done
> with '==', like optimizing for a situation where 'equals' is likely to be
> true. (I'm sympathetic to "don't do that anyway!", but it's more of a
> convention thing that javac would tend not to get involved with.)
>
>

From izzeldeen03 at gmail.com  Thu Apr 28 16:15:44 2022
From: izzeldeen03 at gmail.com (Izz Rainy)
Date: Thu, 28 Apr 2022 17:15:44 +0100
Subject: Explicit declaration of val types
Message-ID: <CA+w=8WDmUtXHFu1bwiKKx8dvvdzFyA8nqBTnh54mUbqtVmxCzw@mail.gmail.com>

I second Qu?n Anh's suggestion to allow explicitly choosing a name for the
val type, rather than just qualifying the ref type (or vice versa) - and I
think this would be better than using a seperate modifier entirely.

1. Using a seperate declaration is just less weird than a modifier. While
other modifiers/decorations can bring in new implicit members (like
record-ness, enum-ness, or inner class static-ness), those always either
use a name chosen by the user (component name, outer class name) or a
standard name (toString, valueOf) with an explicit definition *somewhere*.

2. It makes it more clear where the val type comes from. Instead of having
"one class, two types" unlike anything else, it's just "two definitions,
two types, one is a little weird". You also get a convenient
go-to-definition target for it.

3. Neither type is "favoured" or "default" anymore - the user doesn't have
to spend extra effort reading and writing code that uses the val or ref
type, and the language no longer makes a judgement on which one you
"should" be using.

4. It makes Integer/int, Character/char, etc even less special. You can
define your own `Complex` and `complex` types, and apply everything you
already know about the built-in types to your types instead of relearning
it in terms of vals and refs.

5. Subjective, but it's just stylistically better. Helps avoid having 3
different class modifiers that all just mean "slightly more value-like",
and makes your code look more like regular java code with primitives and
boxes, especially if a lower-snake-case convention is used for val types.

You can also imagine restricting the visibility of the val type, so that
only (trusted) code internal to your library can bypass the constructor,
but it's probably better to define a seperate primitive type with less
visibility and a less visible constructor using that type.

You could also imagine allowing users to specify _ as the ref type name
when a val companion is present to just make it something.red, to allow the
author to make it very clear not to use the reference type except where
necessary (e.g. by non-universal generics), but decoupling top-level type
name from file name is probably a stretch for not much benefit.