-
Notifications
You must be signed in to change notification settings - Fork 5.8k
JDK-8305593: Add @spec tags in java.desktop #13360
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-8305593: Add @spec tags in java.desktop #13360
Conversation
👋 Welcome back jjg! A progress list of the required criteria for merging this PR into |
@jonathan-gibbons The following label will be automatically applied to this pull request:
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. |
Webrevs
|
@@ -587,6 +587,8 @@ public void mail() throws IOException { | |||
* {@code AWTPermission("showWindowWithoutWarningBanner")} | |||
* permission, or the calling thread is not allowed to create a | |||
* subprocess | |||
* @spec https://www.rfc-editor.org/info/rfc2368 | |||
* RFC 2368: The mailto URL scheme |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The javadoc above references ietf.org. This tag references rfc-editor.org. It seems odd to use two different URLs
in the same method specification for the same RFC. I would have thought the ietf one better to use .. although it should be updated to https
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This work is primarily about adding @spec
tags, in a semi-automated fashion, using a custom utility that scans comments in the public API, looking for href
s to "well-known" sites hosting external specifications. While "mostly automated", I did manually cleanup the references by line-wrapping as appropriate.
It is out of scope at this time to cleanup up the underlying href
s, although we should look at cleaning up those links later, identifying the latest/preferred URL for the appropriate version of the spec document, which may or may not be the latest overall version of the spec. (For example, the client docs reference HTML 3.2, and should not reference anything more recent.). This cleanup can be done later and needs to be done in conjunction with the relevant teams, and probably not as a semi-automated update. Such cleanup should be somewhat easier once we have tagged the affected comments with the relevant @spec
tags.
I note that once we have completed the addition of the @spec
tags, we will, re-enable the new "External Specifications" page, which cross-references where each individual external specification is mentioned in the overall API documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, but no matter how many times I try, it seems wrong to even for some short amount of time to have @SPEC point to one place and the javadoc point to another. They should always be consistent.
If it is out of scope to update the javadoc, then the new spec tag should just match the existing javadoc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the rfc-editor.org
that's going to be hard, insofar as there are strong opinions (voiced in an earlier round of review) about using references to the old sites.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see just 18 references matching href=....ietf.org
so I guess I can manually update those for you.
$ grep -r 'href=[^ ]*ietf.org' open/src/java.desktop
open/src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java: See <a href=http://www.ietf.org/rfc/rfc2083.txt>RFC2083</a> for details. */
open/src/java.desktop/share/classes/java/awt/Desktop.java: * href="http://www.ietf.org/rfc/rfc2368.txt">The mailto URL
open/src/java.desktop/share/classes/java/awt/peer/DesktopPeer.java: * <a href="http://www.ietf.org/rfc/rfc2368.txt">RFC2368: The mailto
open/src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java: * <a href="http://www.ietf.org/rfc/rfc1952.txt">RFC 1952</a>.
open/src/java.desktop/share/classes/javax/print/attribute/standard/MediaSizeName.java: * <a href="http://www.ietf.org/rfc/rfc2911.txt">RFC 2911</a>
open/src/java.desktop/share/classes/javax/print/attribute/standard/Fidelity.java: * <a href="http://www.ietf.org/rfc/rfc2911.txt">RFC 2911</a> Section 15.1 for a
open/src/java.desktop/share/classes/javax/print/attribute/standard/package-info.java: * <a href="http://www.ietf.org/rfc/rfc2911.txt">RFC 2911</a> for more
open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * <a href="http://www.ietf.org/rfc/rfc2045.txt">RFC 2045</a> and
open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * <a href="http://www.ietf.org/rfc/rfc2046.txt">RFC 2046</a>) that specifies
open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * <a href="http://www.ietf.org/rfc/rfc2046.txt">RFC 2046</a>, which says the
open/src/java.desktop/share/classes/javax/print/DocFlavor.java: * <a href="http://www.ietf.org/rfc/rfc2278.txt">
open/src/java.desktop/share/classes/javax/print/package-info.java: * <a href="http://www.ietf.org/rfc/rfc2911.txt">RFC 2911 Internet Printing
open/src/java.desktop/share/classes/javax/print/MimeType.java: * <a href="http://www.ietf.org/rfc/rfc2045.txt">RFC 2045</a> and
open/src/java.desktop/share/classes/javax/print/MimeType.java: * <a href="http://www.ietf.org/rfc/rfc2046.txt">RFC 2046</a>. A MIME type
open/src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java: * @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a>
open/src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java: * <a href="https://tools.ietf.org/html/rfc2306.html">TIFF-F</a> (RFC 2036) file.
open/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html:<td><a href="https://tools.ietf.org/html/rfc1950">
open/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html:<a href="https://tools.ietf.org/html/rfc1951">
$ grep -r 'href=[^ ]*ietf.org' open/src/java.desktop | wc -l
18
@@ -222,7 +222,8 @@ public final class BaselineTIFFTagSet extends TIFFTagSet { | |||
* A value to be used with the "Compression" tag. | |||
* | |||
* @see #TAG_COMPRESSION | |||
* @see <a href="https://tools.ietf.org/html/rfc1951">DEFLATE specification</a> | |||
* @spec https://www.rfc-editor.org/info/rfc1951 | |||
* RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 | |||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. So why are you preferring this rfc-editor.org site ?
Seems we should get that cleared up before I look further
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we were strongly recommended to do so, in an earlier round of review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea who that person is with the strong opinions, and hence no idea of his standing to assert the opinion.
So I'd be reluctant to follow his suggestion without more info.
But they still should be the same.
On the use of So, despite being a non-obvious host name, it seems like this is the preferred long-term place for references to RFCs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All LGTM.
@jonathan-gibbons 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:
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 120 new commits pushed to the
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 |
/integrate |
Going to push as commit 34f0a6e.
Your commit was automatically rebased without conflicts. |
@jonathan-gibbons Pushed as commit 34f0a6e. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review a docs-only change to add
@spec
tags intojava.desktop
public API filesProgress
Issue
"3"
)Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13360/head:pull/13360
$ git checkout pull/13360
Update a local copy of the PR:
$ git checkout pull/13360
$ git pull https://git.openjdk.org/jdk.git pull/13360/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13360
View PR using the GUI difftool:
$ git pr show -t 13360
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13360.diff
Webrev
Link to Webrev Comment