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

JDK-8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives #14574

Closed
wants to merge 7 commits into from

Conversation

jddarcy
Copy link
Member

@jddarcy jddarcy commented Jun 21, 2023

Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives (Bug - P4)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14574

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14574.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 21, 2023

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

@openjdk openjdk bot added the rfr Pull request is ready for review label Jun 21, 2023
@openjdk
Copy link

openjdk bot commented Jun 21, 2023

@jddarcy The following label will be automatically applied to this pull request:

  • core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the core-libs core-libs-dev@openjdk.org label Jun 21, 2023
@mlbridge
Copy link

mlbridge bot commented Jun 21, 2023

Webrevs

@@ -812,14 +812,19 @@ public Void run() {
*
* <p> There are nine predefined {@code Class} objects to represent
* the eight primitive types and void. These are created by the Java
* Virtual Machine, and have the same names as the primitive types that
* Virtual Machine, and have the same {@linkplain #getName() names} as the primitive types that
* they represent, namely {@code boolean}, {@code byte},
* {@code char}, {@code short}, {@code int},
* {@code long}, {@code float}, and {@code double}.
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 {@code void} to the list here, as this is one of the primitive type names?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm. I'll consider that. The javadoc in java.lang.Class is inconsistent in the formatting of "void" as a type name, some instances are in code markup while others are not.

Copy link
Member

Choose a reason for hiding this comment

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

@liach please have a look at this intensive exchange between David Holmes (@dholmes-ora) and me: #6213 (comment) That exchange relates to other keywords that might appear in plain (i.e. prose) font.

Speaking of which, I might still owe David a follow-up PR.

Choose a reason for hiding this comment

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

@jddarcy and @pavelrappo, as I understood it, @liach is not suggesting that the term "void" in "primitive types and void" should be replaced by {@code void}.

Rather, {@code void} should be included in the enumeration of primitive types -- for example, by replacing and {@code double} with {@code double}, and {@code void}.

Copy link
Member

Choose a reason for hiding this comment

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

@jddarcy and @pavelrappo, as I understood it, @liach is not suggesting that the term "void" in "primitive types and void" should be replaced by {@code void}.

Rather, {@code void} should be included in the enumeration of primitive types -- for example, by replacing and {@code double} with {@code double}, and {@code void}.

AFAIK, that sentence enumerates primitive types, which according to the Java Language Specification 12, do not include void.

Footnotes

  1. https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-4.2

  2. https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.4.5

Copy link

@sbrannen sbrannen Jun 23, 2023

Choose a reason for hiding this comment

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

Thanks for the links, @pavelrappo.

I understand the point you're making; however, there is still ambiguous wording in the documentation for this method.

The method is called isPrimitive, and it returns true for isPrimitive(void.class). In addition, the first sentence states: "Determines if the specified Class object represents a primitive type."

Note as well that the documentation states "There are nine predefined ..." but then goes on to only list 8 names.

So, in line with the intent of the method with regard to void, it should be clear to the user that void is the name for the type void.class (and Void.TYPE).

Perhaps the easiest way to include void.class and match the 9 predefined types with their names is to remove "primitive" from "as the primitive types that" and replace and {@code double} with {@code double}, and {@code void}.

Along that line of thinking, it might be best to change the first sentence to "Determines if the specified Class object represents a primitive type or void." And the return statement should be changed to @return true if and only if this class represents a primitive type or void.

Copy link
Member

@pavelrappo pavelrappo Jun 23, 2023

Choose a reason for hiding this comment

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

Along that line of thinking, it might be best to change the first sentence to "Determines if the specified Class object represents a primitive type or void."

I was just about to suggest exactly that, but from the superinterface method's perspective. Here's what I had been writing when received your message:

At the same, time java.lang.invoke.TypeDescriptor.OfField#isPrimitive:

    /**
     * Does this field descriptor describe a primitive type (including void.)
     *
     * @return whether this field descriptor describes a primitive type
     */
    boolean isPrimitive();

I suggest rephrasing that and similar text elsewhere, for example, as follows:

/** {@return whether this field descriptor describes a primitive type or void} */
boolean isPrimitive();

Copy link
Member Author

Choose a reason for hiding this comment

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

The functionality of the method is "isPrimitiveTypeOrVoid" as void is technically not a type, etc.; however, the method is named "isPrimitive" and that is most of what it does.

* <p>No other class objects are considered primitive.
*
* @apiNote
* These {@code Class} objects can be accessed via the {@code
Copy link
Contributor

Choose a reason for hiding this comment

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

It might be clearer if the API note starts with something like "A Class object representing a primitive type" rather than "These Class objects".

* <p>No other class objects are considered primitive.
*
* @apiNote
* A {@code Class} object represented a primitive type can be
Copy link
Member

Choose a reason for hiding this comment

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

Not a native speaker, but "representED" not "representING"?

Copy link
Member

@pavelrappo pavelrappo left a comment

Choose a reason for hiding this comment

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

Looks good to me.

@openjdk
Copy link

openjdk bot commented Jun 23, 2023

@jddarcy 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:

8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives

Reviewed-by: prappo

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 13 new commits pushed to the master 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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jun 23, 2023
@pavelrappo
Copy link
Member

pavelrappo commented Jun 23, 2023

Only after I have approved the change, did I re-read the whole thing again. Would you be able to fix this in this PR too? (Sorry.)

    /**
     * Determines if the specified {@code Class} object represents a
     * primitive type.
...

There's no "specified class object", it's this class object. That method has zero parameters.

@jddarcy
Copy link
Member Author

jddarcy commented Jun 23, 2023

/integrate

@openjdk
Copy link

openjdk bot commented Jun 23, 2023

Going to push as commit 0314292.
Since your change was applied there have been 13 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jun 23, 2023
@openjdk openjdk bot closed this Jun 23, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jun 23, 2023
@openjdk
Copy link

openjdk bot commented Jun 23, 2023

@jddarcy Pushed as commit 0314292.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@sbrannen
Copy link

Thanks for improving the documentation, @jddarcy. 👍

@jddarcy jddarcy deleted the JDK-8310267 branch October 17, 2024 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

5 participants