-
Notifications
You must be signed in to change notification settings - Fork 5.8k
JDK-8266748: Move modifiers code to Signatures.java #4142
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
👋 Welcome back hannesw! A progress list of the required criteria for merging this PR into |
Webrevs
|
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.
General comments; not a final review.
-
Moving code out of
Utils
is generally always good but it's a bit of a shame to move it down intoformats.html
. That being said,Signatures
is a good abstraction to be building. -
The medium amount of use of
HtmlDocletWriter
inSignatures
is a code-smell, although arguably, we're just exposing an existing code-smell. We should (generally) continue our efforts to move code out ofHtmlDocletWriter
into other more-focussed abstractions.
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.
Minor changes suggestion, to access items from the configuration where possible.
As a followup, it would be good to look at the remaining uses of HtmlDocletWriter
in Signatures
. There is at least a theme of "methods to create links", and if those methods are just used in the Signatures
class, they would be candidates to move into that class as well.
if (!annotationInfo.isEmpty()) { | ||
content.add(HtmlTree.SPAN(HtmlStyle.annotations, annotationInfo)); | ||
} | ||
content.add(HtmlTree.SPAN(HtmlStyle.modifiers, modifiers)); | ||
|
||
HtmlTree nameSpan = new HtmlTree(TagName.SPAN).setStyle(HtmlStyle.elementName); | ||
Content className = Text.of(utils.getSimpleName(typeElement)); | ||
if (classWriter.options.linkSource()) { | ||
classWriter.addSrcLink(typeElement, className, nameSpan); | ||
if (writer.options.linkSource()) { |
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.
better to use configuration.getOptions()
HtmlLinkInfo.Kind.PERMITTED_SUBCLASSES, | ||
type)); | ||
permitsSpan.add(link); | ||
} | ||
if (linkablePermits.size() < permits.size()) { | ||
Content c = Text.of(classWriter.resources.getText("doclet.not.exhaustive")); | ||
Content c = Text.of(writer.resources.getText("doclet.not.exhaustive")); |
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.
Better to use configuration.getDocResources()
writer.htmlIds.forPreviewSection(typeElement), | ||
writer.contents.previewMark))); |
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.
use the configuration for these two values
I changed the mentioned accesses to use configuration instead of writer. Most of the link methods in |
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.
Generally good, and as with many cleanups, it's a great step in the right direction. As I indicated in a previous round of review, I think that further cleanup is possible (later) by moving more code out of HtmlDocletWriter
into more specific abstractions, possibly including this one.
@hns 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 259 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 |
@hns Since your change was applied there have been 264 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit f9b593d. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This change consolidates the code to generate type signature modifiers into
Signatures.TypeSignature
.Although this mostly consists of moving the code from
ClassWriterImpl
andUtils
toSignatures
, I also avoided the need to split the modifiers string when processing preview modifiers by returning aList<String>
instead of aString
in what used to beUtils.modifiersToString
and is nowTypeSignature.getModifiers
.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4142/head:pull/4142
$ git checkout pull/4142
Update a local copy of the PR:
$ git checkout pull/4142
$ git pull https://git.openjdk.java.net/jdk pull/4142/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4142
View PR using the GUI difftool:
$ git pr show -t 4142
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4142.diff