-
Notifications
You must be signed in to change notification settings - Fork 6.2k
JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) #790
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
Conversation
…uments referenced from javadocs (OEM spec)
|
👋 Welcome back jjg! A progress list of the required criteria for merging this PR into |
|
@jonathan-gibbons The following labels 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 lists. If you would like to change these labels, use the /label pull request command. |
|
/issue add JDK-8226279 |
|
@jonathan-gibbons |
|
/csr |
|
@jonathan-gibbons has indicated that a compatibility and specification (CSR) request is needed for this pull request. |
erikj79
left a comment
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.
Build changes look good.
hns
left a comment
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.
It's very instructive to see a new tag introduced from scratch with all the accompanying infrastructure and tests. The changes looks good to me, but I need to stress than I'm not an expert on some of the affected areas such as the jdk.compiler parts.
|
@jonathan-gibbons this pull request can not be integrated into git checkout new-spec-tag
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
| /** | ||
| * Creates a new {@code SpecTree} object, to represent a {@code @spec} tag. | ||
| * | ||
| * @param inline whether this is instance is an inline tag |
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.
Should be:
* @param inline whether this instance is an inline tag
pavelrappo
left a comment
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.
- Thanks for incorporating my previous offline feedback.
- Since Hannes and Erik seem to have looked at everything else, I looked mostly at changes in
src/jdk.compiler/share/classes/com/sun/source/**, which are good! - There should be a corresponding but separate change to "Documentation Comment Specification for the Standard Doclet".
- Can we use this new
@sincetag to refer to the spec atcom/sun/tools/javac/parser/DocCommentParser.java:1116? - Should we specify in
com.sun.source.doctree.SpecTreethat bothurlandlabelparts are mandatory? DCSpec extends DCEndPosTree, sigh... Although that is not a public API, this design suggests we could improve that abstraction sometime later.
|
|
||
| abstract DCTree parse(int pos) throws ParseException; | ||
| DCTree parse(int pos, Kind kind) throws ParseException { | ||
| if (kind != this.kind && this.kind != Kind.EITHER) { |
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 condition looks right, but shouldn't we add another one to guard against accidental passing of kind == EITHER?
| * Creates an HTML {@code A} element. | ||
| * The {@code ref} argument will be URL-encoded for use as the attribute value. | ||
| * | ||
| * @param ref the value for the {@code href} attribute} |
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.
Since you are here, could you please remove that trailing }?
| * and will <i>not</i> be additionally URL-encoded, but will be | ||
| * {@link URI#toASCIIString() converted} to ASCII for use as the attribute value. | ||
| * | ||
| * @param ref the value for the {@code href} attribute} |
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.
One more, perhaps copy-pasted, trailing }.
| @@ -0,0 +1,32 @@ | |||
| /* | |||
| * Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights reserved. | |||
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.
Should be:
Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
| HtmlTree.DD(body)); | ||
| } | ||
|
|
||
| String textOf(List<? extends DocTree> trees) { |
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 wonder if this method should work recursively rather than shallowly. Consider the following example:
@spec http://example.com Some code: {@code text}
I reckon we'll end up with only Some code: .
| public boolean isBlank() { | ||
| return false; | ||
| } | ||
|
|
||
| public static boolean isBlank(List<? extends DCTree> list) { | ||
| return list.stream().allMatch(DCTree::isBlank); | ||
| } | ||
|
|
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.
Adding these two methods here might be overkill.
|
|
||
| for (Taglet t : taglets) { | ||
| String name = t.isInlineTag() ? "{@" + t.getName() + "}" : "@" + t.getName(); | ||
| String name = t.isBlockTag() ? "@" + t.getName() : "{@" + t.getName() + "}"; |
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.
Out of curiosity, why did you flip that?
|
Closing pull request, until we better decide the contents of the spec page |
This introduces support for a new
@spectag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.As an inline tag, the format is
{@spec url label}, which is roughly translated to<a href="url">label</a>in the generated docs.As a block tag, the format is simply
which is handled in a manner analogous to
The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as
{@jls}and{@jvms}.) To support bimodal standard tags, some changes toDocCommentParserare incorporated here.This change is only the support for the new tag; it does not include any changes to API docs to use the new tag.
Progress
Testing
Integration blocker
Issues
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/790/head:pull/790$ git checkout pull/790