Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8346035: [lworld] javadoc for value objects when enable preview #1316

Open
wants to merge 3 commits into
base: lworld
Choose a base branch
from

Conversation

RogerRiggs
Copy link
Collaborator

@RogerRiggs RogerRiggs commented Dec 11, 2024

Updated javadoc for value objects when preview is enabled.

Added text and decoration to highlight preview behavior of identity classes that are value classes with --enable-preview
The decorations are similar to the existing preview highlights for Preview classes and methods.

The updates include all of the wrapper classes, java.time, and java.util.Optional* and other classed annotated with @valuebased.

The ValueBased is updated to describe the behavior when --enable-preview.


Progress

  • Change must not contain extraneous whitespace

Issue

  • JDK-8346035: [lworld] javadoc for value objects when enable preview (Bug - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/1316/head:pull/1316
$ git checkout pull/1316

Update a local copy of the PR:
$ git checkout pull/1316
$ git pull https://git.openjdk.org/valhalla.git pull/1316/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1316

View PR using the GUI difftool:
$ git pr show -t 1316

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/1316.diff

Using Webrev

Link to Webrev Comment

Added text and decoration to highlight preview behavior of
identity classes that are value classes with --enable-preview
@bridgekeeper
Copy link

bridgekeeper bot commented Dec 11, 2024

👋 Welcome back rriggs! A progress list of the required criteria for merging this PR into lworld will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Dec 11, 2024

@RogerRiggs This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8346035: [lworld] javadoc for value objects when enable preview

Reviewed-by: liach

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 1 new commit pushed to the lworld branch:

  • c4f1714: 8345250: [lworld] C2: Array loads and stores on inexact flat arrays cause crashes

Please see this link for an up-to-date comparison between the source branch of this pull request and the lworld branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

@openjdk openjdk bot added the rfr label Dec 11, 2024
@mlbridge
Copy link

mlbridge bot commented Dec 11, 2024

Webrevs

* The {@code equals} method should be used for comparisons.
* class; programmers should treat instances that are {@linkplain #equals(Object) equal}
* as interchangeable and should not use instances for synchronization, mutexes, or
* with {@linkplain java.lang.ref.Reference object references}.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add the preview warning with rewords, like

When preview features are enabled, all implementations of {@code ZoneId} are {@linkplain Class#isValue value class}. ...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's more to do before ZoneId can be a Valhalla value class.
Its subtype ZoneOffset has a non-final field that caches ZoneRules. So ZoneOffset can't be a value class.

@RogerRiggs RogerRiggs changed the title 8346035: javadoc value cleanup 8346035: [lworld] javadoc for value objects when enable preview Dec 12, 2024
@openjdk openjdk bot added the ready label Dec 12, 2024
Copy link
Member

@liach liach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Looks good to me.

* <div class="preview-comment">
* When preview features are enabled, {@code Record} is
* an abstract {@linkplain Class#isValue value class}.
* Subclasses of {@code Number} can be either an {@linkplain Class#isIdentity identity class}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Number/Record/

visible change in the behavior of the class's methods;</li>
<li>the class performs no synchronization using an instance's monitor;</li>
<li>the class does not declare (or has deprecated any) accessible constructors;</li>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is still relevant, as a concrete case of the next bullet, right? A value-based class should not let clients control identity creation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could maybe soften to "(or discourages use of any)"...

serialization, or any other identity-sensitive mechanism.</p>

<p>Synchronization on instances of value-based classes is strongly discouraged,
because the programmer cannot guarantee exclusive ownership of the
associated monitor.</p>

<p>Identity-related behavior of value-based classes may change in a future release.
For example, synchronization may fail.</p>
<p>When preview features are enabled, use of value class instances for synchronization, mutexes, or with
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A value-based class is not necessarily a value class under preview.

I think this "behavior may change" disclaimer is trying to cover two cases, which should probably be identified directly:

  • The class may choose to allocate/cache instances differently
  • The class may choose to become a value class, and then [things may fail]

* occur. For example, in a future release, synchronization may fail.
* class; programmers should treat instances that are {@linkplain #equals(Object) equal}
* as interchangeable and should not use instances for synchronization, mutexes, or
* with {@linkplain java.lang.ref.Reference object references}.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a preview feature disclaimer for References.

Is there a similar one for mutexes? (What exactly do you mean by "mutexes"? Is it distinct from "synchronization"?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants