Hello,
Please review the following change for
https://bugs.openjdk.java.net/browse/JDK-8234746:
http://cr.openjdk.java.net/~prappo/8234746/webrev.00/
Before:
javax.rmi.ssl.client.enabledCipherSuites - Search tag in
javax.rmi.ssl.SslRMIClientSocketFactory
javax.rmi.ssl.client.enabledCipherS
Hello,
Please review the following change for
https://bugs.openjdk.java.net/browse/JDK-8235435:
http://cr.openjdk.java.net/~prappo/8235435/webrev.00/author.patch
This change removes occurrences of @author tags throughout the source files and
tests in Javadoc. It cleanly removes all the tag
gletWriterImpl.java:
>
> line 429: DocPaths docPaths = configuration.docPaths;
> line 433: TypeElement te = utils.getEnclosingTypeElement(e);
>
> Would be nice to clean those up while you’re at it.
Done.
> Hannes
>
>
>> Am 25.11.2019 um 18:19 schrieb Pavel Rap
Hey Jon, thanks for looking at it. I have updated the webrev. This new webrev
addresses Hannes' and yours comments:
http://cr.openjdk.java.net/~prappo/8234746/webrev.01/
-Pavel
> On 27 Nov 2019, at 21:20, Jonathan Gibbons
> wrote:
>
>
>
>
> On 11/25/2019 0
Hannes,
Thanks for doing this! Looks good.
> On 10 Dec 2019, at 17:12, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235670
> Webrev: http://cr.openjdk.java.net/~hannesw/8235670/webrev.00/
> API docs: http://cr.openjdk.java.net/~hannesw/82356
Hannes,
Looks good.
> On 10 Dec 2019, at 16:12, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8233866
> Webrev: http://cr.openjdk.java.net/~hannesw/8233866/webrev.00/
> API docs: http://cr.openjdk.java.net/~hannesw/8233866/api.00/
>
> This is
Hello,
Please review the following change for
https://bugs.openjdk.java.net/browse/JDK-8215038:
http://cr.openjdk.java.net/~prappo/8215038/webrev.00/
This change proposes a summary page for system properties. The change is
largely based on prior work of Priya Lakshmi Muthuswamy (pmuthuswam
use for the "Referenced In" column. It fit better with the
> package and class references.
>
> And yes, any index is better than none.
>
> Thanks, Roger
>
>
> On 12/11/19 12:26 PM, Pavel Rappo wrote:
>> Hello,
>>
>> Please review
ent. As for the "vertical
separator", I decided not to touch it right now. The "|" separator is used in
navbar too. There's a possibility of reuse. We should refactor it separately.
-Pavel
> On 11 Dec 2019, at 17:26, Pavel Rappo wrote:
>
> Hello,
>
Hello,
Please review the following change for
https://bugs.openjdk.java.net/browse/JDK-8235447:
http://cr.openjdk.java.net/~prappo/8235447/webrev.00/
This is a cleanup task. The above change removes @author (and the associated
@since) tags from javadoc *tests* where those tags are not intri
Jon,
The idea of the fix looks reasonable. Since I'm new to javadoc, I have more
questions than would
probably be expected during a typical review.
1. Could you help me understand the asymmetry in BaseTaglet?
public boolean accepts(DocTree tree) {
return (tree.getKind() == DocTree.K
Jon,
> On 16 Dec 2019, at 19:00, Jonathan Gibbons
> wrote:
>
> On 12/16/2019 10:44 AM, Pavel Rappo wrote:
>> Jon,
>>
>> The idea of the fix looks reasonable. Since I'm new to javadoc, I have more
>> questions than would
>> probably be expect
Jon,
> On 16 Dec 2019, at 19:56, Jonathan Gibbons
> wrote:
>
> On 12/16/19 11:45 AM, Pavel Rappo wrote:
>> Jon,
>>
>>> On 16 Dec 2019, at 19:00, Jonathan Gibbons
>>> wrote:
>>>
>>> On 12/16/2019 10:44 AM, Pavel Rappo wrote:
>
Hello,
Please review the following trivial change for
https://bugs.openjdk.java.net/browse/JDK-8236077:
http://cr.openjdk.java.net/~prappo/8236077/webrev.00/
This is a cleanup task. The above change removes the redundant modifiers (e.g.
"public abstract" for
interface methods). This allows
Jon,
Could you please explain why "generated files should only contain \n"?
Is it possible to perform the `rawHtml.indexOf('\r') == -1` optimization check
first thing in
normalizeNewlines?
New mechanics of string normalization is more readable, albeit is probably
slower in a typical case.
Old
Three dates are created in succession: (1) `startDate` on MetaTag:103, (2)
`startTime` on HtmlConfiguration:265, and `date`
on MetaTag:95. If dates (1) and (3) are equal, we then conclude that (2) must
be the same as (1) and (3). If I read the intent correctly, this implication
warrants the cond
Hello,
Please review the following change for
https://bugs.openjdk.java.net/browse/JDK-8236700:
http://cr.openjdk.java.net/~prappo/8236700/webrev.00/
This change upgrades the JSZip JavaScript library, used in Javadoc Search [1],
to v3.22. I tested this change as follows.
1. Commented out l
I like it.
When comparing the wording for the corresponding option for javac I noticed that
it is more vague than that of the proposed for javadoc:
-Werror Terminate compilation if warnings occur (javac)
-Werror: treat warnings as if they were errors (proposed for javadoc)
Does the latt
Hi Jon,
> On 17 Jan 2020, at 18:25, Jonathan Gibbons
> wrote:
>
> Hi Pavel,
>
> Good feedback.
>
> The javadoc wording was deliberately more vague, because I couldn't think of
> anything accurate and more specific to say. Essentially, we just want to
> convey/enable one bit of info ... you
Jon,
I don't have a strong opinion on this refactoring. I will rely on your judgment
and the fact that you know that code well.
My initial reaction was "Isn't it violating the Law of Demeter or something?"
But on a closer look, I understood that it was merely a restructuring action.
What you seem
Looks good.
> On 21 Jan 2020, at 21:18, Jonathan Gibbons
> wrote:
>
> Please review a tiny changeset (inline below) to fix the typography in some
> short javadoc comments.
>
> No semantic changes, so no CSR.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8237597
>
>
> diff
Hello,
Please review the following (documentation) change for
https://bugs.openjdk.java.net/browse/JDK-8233795:
http://cr.openjdk.java.net/~prappo/8233795/webrev.00/
The detailed explanation can be found in the description in the JBS issue.
Thanks,
-Pavel
> On 21 Jan 2020, at 18:55, Jonathan Gibbons
> wrote:
>
> Pavel,
>
> All great feedback, and all points addressed, as described in the details
> inline below.
>
> New webrev, addresses all your comments, adds a couple of class-level doc
> comments
> to the two new classes, and fixes a couple
> On 22 Jan 2020, at 19:29, Jonathan Gibbons
> wrote:
>
> As the ancient Roman's used to say,
>
> javadoc was not cleaned up in a single changeset.
Reviewed. Thanks.
Thanks, Hannes. Surprisingly enough, the copyright header was missing. I added
it before pushing.
> On 22 Jan 2020, at 13:15, Hannes Wallnöfer
> wrote:
>
> Nice. +1
>
> Hannes
>
>
>> Am 22.01.2020 um 12:58 schrieb Pavel Rappo :
>>
>>
Hi Jon,
I'm still working through the review but I have to say that degree to which
com.sun.tools.javac.main.Option.* types have percolated to the javadoc internal
interfaces is unsettling. I understand this is probably due to practical and
historical reasons. Maybe we could address that later.
d source and class files.
>
> It was actually a big step forward in the JDK 9 rewrite that we properly
> delegate through the underlying Option objects, as compared to tunneling
> values into the compOpts object, as was done previously, which bypassed much
> of javac's che
I was definitely not suggesting that! Rather, I was commenting on what I saw.
The state of affairs, that predate your changeset.
> On 24 Jan 2020, at 17:29, Jonathan Gibbons
> wrote:
>
> Changing all this (especially javac!) is more than I wanted to do in this
> changeset!
The crux of the change is gathering options into a more monolithic and more
encapsulated design. If I were to describe this change in a nutshell, it would
be:
Map -> class ToolOptions
The change, as you described, does away with the enum. So ToolOption.values()
become ToolOptions.getSupported
I remember we had an offline conversation on whether we should use shorter
method names for accessing stuff [ stuff() ], or more familiar ones
[ getStuff()/hasStuff()/isStuff()/etc. ].
I remember saying that I had no strong opinion about it. Not thank I'm
rethinking it, but I can now see how some o
dule. Woohoo!
>
> -- Jon
>
> Webrev: http://cr.openjdk.java.net/~jjg/8237803/webrev.01/
>
>
> On 01/24/2020 11:23 AM, Pavel Rappo wrote:
>> The crux of the change is gathering options into a more monolithic and more
>> encapsulated design. If I were to describe this
How did you generate those javadoc pages?
> On 27 Jan 2020, at 15:45, Roman Leventov wrote:
>
> Foo.java:
> package a;
> class Foo {
> public void foo() {}
> }
>
> Bar.java:
> package a;
> public class Bar extends Foo {}
>
> in generated Javadoc site, foo() method is not listed on the index p
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8237909:
http://cr.openjdk.java.net/~prappo/8237909/webrev.00/
This change removes the "zipped index files" feature, which was introduced as
part of 8141492: Implement search feature in javadoc.
The "zipped index fi
Hannes,
> On 28 Jan 2020, at 17:15, Hannes Wallnöfer
> wrote:
>
> Hi Pavel,
>
> I fully concur with your reasoning for removing the jszip feature.
Removing JSZip is incidental here. It's the whole "zipped index files" feature
that is being removed.
> In script.js you left in the checks whet
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8238167:
http://cr.openjdk.java.net/~prappo/8238167/webrev.00/
This is a cleanup change that removes a couple of files that I have not found
to be of any use.
The first file, jquery.js, was introduced in
changes
> On 30 Jan 2020, at 01:25, Jonathan Gibbons
> wrote:
>
> Please review a moderately simple fix to a regression in the way that javadoc
> handles doclint options.
>
> The feature was introduced in JDK 8, and at that time, the doclet options
> were accumulated in a list.
>
> The regression wa
was pushed yesterday does NOT break anything.
I just felt I had to convey these further findings for the sake of future
maintainers.
I should probably file a follow-up bug that deals with tidying of all that
JS mess.
-Pavel
> On 29 Jan 2020, at 15:39, Pavel Rappo wrote:
>
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8238291:
http://cr.openjdk.java.net/~prappo/8238291/webrev.00/
This is a tiny cleanup change. The goal is to fix inconsistency in abbreviating
the fields of the index structure.
The fields of the index structure, suc
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8238467:
http://cr.openjdk.java.net/~prappo/8238467/webrev.00/
This is a blanket cleanup. The change adds missing @java.lang.Override
annotations
and removes some of the {@inheritDoc} tags. The removed {@inheritDoc}
el
-
[1]
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/hh801214(v=vs.85)?redirectedfrom=MSDN
>
> -- Jon
>
>
> On 01/28/2020 07:55 AM, Pavel Rappo wrote:
>> Hello,
>>
>> Plea
1. Javadoc comments for constructors of the HtmlConfiguration and
BaseConfiguration
classes could be updated. The comment for the HtmlConfiguration ctor could be
deleted, as there's not much value in it. The comment for the BaseConfiguration
ctor should better be updated to reflect the change in t
the description contains a quote character ('"')
> ... there is no attempt to escape any values.
Thanks! I've filed a bug on that, JDK-8238495, and added a corresponding
TODO comment to the code.
-Pavel
> -- Jon
>
>
> On 01/31/2020 05:47 AM, Pavel Rappo wrote:
>>
RFR.
-Pavel
>
> -- Jon
>
>
> On 2/4/20 5:21 AM, Pavel Rappo wrote:
>> Hello,
>>
>> Please review the change for
>> https://bugs.openjdk.java.net/browse/JDK-8238467:
>>
>> http://cr.openjdk.java.net/~prappo/8238467/webrev.00/
>>
>&g
020, at 21:39, Pavel Rappo wrote:
>
> 3. jdk.javadoc.internal.doclets.toolkit.taglets.BaseTaglet#getTagletOutput(3
> parameters)
>jdk.javadoc.internal.doclets.toolkit.taglets.Taglet#getTagletOutput(3
> parameters)
>
> @throws UnsupportedOperationException t
1. The change removes full stops from some places (e.g. @param and @return) and
adds them to others
2. "taglet-writer" hyphenated spelling is used inconsistently across
getTagletOutput methods in Taglet.java
3. 2-parameter getTagletOutput method specifies
@throws UnsupportedOperationException
Jon,
1. The patch has become a tad bit outdated after to your recent push.
Just a heads-up.
2.
145 if (locale == Locale.getDefault()) {
That looks very conservative, I would expect `equals()`. Since it's about
a one-off optimization, it is not a big deal. I just stumbled upon that.
t("doclet.Types"));
...
} else if (category.equals("Types")) {
after:
si.setCategory(SearchIndexItem.Category.TYPES);
...
case TYPES:
See, no magic.
-Pavel
> On 7 Feb 2020, at 16:29, Pavel Rappo wrote:
>
> Jon,
>
> 1. The patch has become a
Jon,
This email is NOT my approval, yet. I'll have to inspect it in more detail,
perhaps over the weekend. However, I may have some comments already.
1. I don't know that code base well, but I'm slowly getting there. The trick
with this change is to make sure that all those configurations are
int
> On 7 Feb 2020, at 18:05, Jonathan Gibbons wrote:
>
> On 2/7/20 9:22 AM, Pavel Rappo wrote:
>> 1. I don't know that code base well, but I'm slowly getting there. The trick
>> with this change is to make sure that all those configurations are
>> interchangeab
concerns.
-Pavel
> On 28 Jan 2020, at 15:55, Pavel Rappo wrote:
>
> Hello,
>
> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8237909:
>
> http://cr.openjdk.java.net/~prappo/8237909/webrev.00/
>
> This change removes the "zipped i
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8238969:
http://cr.openjdk.java.net/~prappo/8238969/webrev.00/
During the last exploratory debugging session, I collected a number of issues
that I think are worth fixing. These include:
1. Indentation, unnecessary (a
> On 13 Feb 2020, at 16:00, Jonathan Gibbons
> wrote:
>
> On 2/13/20 7:50 AM, Pavel Rappo wrote:
>> a. jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java:143
>>
>> Shouldn't it use equals() instead of `==` in this case? A quick look shows
> On 13 Feb 2020, at 18:42, Jonathan Gibbons
> wrote:
>
> On 2/13/20 9:32 AM, Pavel Rappo wrote:
>>> On 13 Feb 2020, at 16:00, Jonathan Gibbons
>>> wrote:
>>>
>>> On 2/13/20 7:50 AM, Pavel Rappo wrote:
>>>> a. jdk/javad
been included in that new webrev. All the tests pass in our CI system.
-Pavel
> On 14 Feb 2020, at 21:57, Jonathan Gibbons
> wrote:
>
> Responding to the details in your message. Comments inline.
>
>
> On 02/13/2020 07:50 AM, Pavel Rappo wrote:
>> Hello,
>&g
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8239243:
http://cr.openjdk.java.net/~prappo/8239243/webrev.00/
I noticed that the index structure, used in Index Page an others, is created
unconditionally (i.e. regardless of the presence of the "-noindex" command-li
tCharacter(String) doesn’t always return the first character
> maybe something like „indexCharacter“ or „keyCharacter“ would be more fitting?
>
> Hannes
>
>
>> Am 17.02.2020 um 16:35 schrieb Pavel Rappo :
>>
>> Hello,
>>
>> Please review the change for
nto either IndexBuilder or a some new abstraction
> to manage these index objects. This would be philosophically similar to the
> recent cleanup to move the collections of fields for options out into
> distinct abstractions.
>
> -- Jon
>
> On 02/18/2020 07:13 AM, Pav
Hi Hannes,
What is the background of this "?is-external=true" feature? How was it used in
the first place? Is there anything I can read on that?
I'm surprised to see the tests' @bug tags are updated to include this bug
number.
I thought that an @bug tag needs to be updated when the test has bee
nges from
> previous webrev.
>
> http://cr.openjdk.java.net/~hannesw/8232438/webrev.01/
>
> Hannes
>
>
>> Am 20.02.2020 um 18:49 schrieb Jonathan Gibbons
>> :
>>
>>
>> On 2/20/20 7:14 AM, Pavel Rappo wrote:
>>> Hi Hannes,
>>>
> On 20 Feb 2020, at 17:49, Jonathan Gibbons
> wrote:
>
> On 2/20/20 7:14 AM, Pavel Rappo wrote:
>> Hi Hannes,
>>
>> What is the background of this "?is-external=true" feature? How was it used
>> in
>> the first place? Is there anything I
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8239876:
http://cr.openjdk.java.net/~prappo/8239876/webrev.00/
This is a cleanup change. For convenience I split it into 3 changesets, called
phase-1, phase-2, and phase-3, which are applied in this particular order.
t; would be good for the record.
>
> -- Jon
>
> On 02/25/2020 05:11 AM, Pavel Rappo wrote:
>> Hello,
>>
>> Please review the change for
>> https://bugs.openjdk.java.net/browse/JDK-8239876:
>>
>> http://cr.openjdk.java.net/~prappo/8239876/webre
I haven't seen webrev.01, so I'll describe what I see in webrev.02.
Some of the affected tests have been made to check for elements, where they
previously didn't:
""
For the record, it's not that those elements were not in the HTML in the
first place, it's just the tests are now checking t
> On 27 Feb 2020, at 21:11, Jonathan Gibbons
> wrote:
>
> Please review the next round of update for definition lists in the generated
> docs.
>
> The primary focus of this round is to ensure that all elements have the
> class attribute set.
>
> In practice, there are only two kinds of defi
That's fine. However, there's still a *directory*, called
"testExternalOverridenMethod"
$ find . -iname "*overriden*"
./test/langtools/jdk/javadoc/doclet/testExternalOverridenMethod
> On 28 Feb 2020, at 19:00, Jonathan Gibbons
> wrote:
>
> On 02/28/
ctories, nor can I do anything to the
> main repo
> to make the empty directory in your repo go away.
>
> `rmdir` is your friend.
>
> -- Jon
>
> On 2/28/20 11:47 AM, Pavel Rappo wrote:
>> That's fine. However, there's still a *directory*, called
&g
Looks good to me.
> On 5 Mar 2020, at 02:05, Jonathan Gibbons wrote:
>
> http://cr.openjdk.java.net/~jjg/8240555/webrev.00/
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8239487:
http://cr.openjdk.java.net/~prappo/8239487/webrev.00/
This change addresses 2 closely related issues on the "System Properties Page":
8239485: Define behavior of the System Properties page when no system
1. BodyContents, Head, Table, and TableHeader are now of type Content.
2. Navigation.Position.{TOP, BOTTOM} is used instead of `boolean top`.
PageMode's ALL_CLASSES, CONSTANT_VALUES, DOC_FILE, SERIALIZED_FORM,
SYSTEM_PROPERTIES, etc. are changed to use _ (underscore) in their names.
3. Many conve
Jon, the replies are inline and the updated webrev is here:
http://cr.openjdk.java.net/~prappo/8239487/webrev.01/
> On 7 Mar 2020, at 01:53, Jonathan Gibbons wrote:
>
> phase-1
>
> In AbstractIndexWriter,
> the use of "anyOf" with a singleton list seems a bit weird.
I've changed methods' n
i Pavel,
>
> The System Properties page looks better with the links qualified by class or
> package, or
> the html document title. Developers will want to have a on their
> document
> so the properties listing is most informative.
>
> Thanks, Roger
>
> On 3/6/
; again.
Sorry about that.
> ---
>
> Ther's some naming stuff and minor feedback, but I think you're getting close.
>
> -- Jon
>
>
> On 03/09/2020 10:48 AM, Pavel Rappo wrote:
>> Jon, the replies are inline and the updated webrev is here:
>>
>> http://
Oops. Here is a link to the forgotten updated webrev:
http://cr.openjdk.java.net/~prappo/8239487/webrev.02/
> On 10 Mar 2020, at 15:45, Pavel Rappo wrote:
>
> The replies are inline.
>
>> On 10 Mar 2020, at 02:11, Jonathan Gibbons
>> wrote:
>>
>> Met
This is in comparison to creating an empty
> enclosing component and then building and adding the individual child
> components.
>
> And, all of these are better that some of the weirder patterns that exist in
> the code today.
>
> -- Jon
>
> On 03/09/2020 04:38 AM, Pavel
Hi Jon,
1. Some methods, constructors, enum constants, and unused imports have gone.
2. HtmlTree.HEADING(..., boolean printTitle, ...) has been split into 2 methods,
HtmlTree.HEADING and HtmlTree.HEADING_TITLE.
On a related note, it's satisfying to see that more and more calls to "new
HtmlTre
This is really nice. Incidentally, it also makes
https://bugs.openjdk.java.net/browse/JDK-8234395
less relevant.
-Pavel
> On 12 Mar 2020, at 20:50, Jonathan Gibbons
> wrote:
>
> Please review a simple fix regarding the non-standard use of some CSS in some
> doc comments.
>
> From the JBS
This looks good to me.
> On 13 Mar 2020, at 21:51, Jonathan Gibbons
> wrote:
>
> Please review a mostly-trivial rename of HtmlTag to TagName, as discussed
> after the recent review for updating HtmlTree.
>
> The rename was a single automated IDE operation.
>
> In addition, some minor functio
These lines are commented out:
65 ///**
66 // * The HTML tree for main tag.
67 // */
68 //private final HtmlTree mainTree = HtmlTree.MAIN();
69
Do you intend to leave them like this?
Otherwise, looks good to me. Thanks.
-Pavel
> On 19 Mar 2020, at 00:43, Jonathan Gibb
Hi Jon,
The proposed patch does fix the issue in question. That said, I noticed one more
visual difference between the current L&F and that of before JDK-8240916:
the font size of search result items.
Long story short, there's one more class name we forgot to change, "resultItem".
I'm not sure th
n 3/20/20 8:04 AM, Jonathan Gibbons wrote:
>> Thanks for the response; I'll check out "resultItem".
>>
>> -- Jon
>>
>> On 3/20/20 3:56 AM, Pavel Rappo wrote:
>>> Hi Jon,
>>>
>>> The proposed patch does fix the issue in que
Hi Jon,
It's nice to see this change addresses a visual regression caused by the recent
changes. Thanks for providing detailed comments for "additional class names"
in the new test.
Nit. Could you change the name of `addExtraCSSClassNames` to
`addExtraCSSClassNamesTo`
or, better still, rename it
---
[1] https://en.wikipedia.org/wiki/Line_wrap_and_word_wrap
[2]
https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html
> With kind regards,
>
> Ivan
>
> [1]
> https://docs.oracle.com/en/java/javase/14/docs/api/java.base/
sted we'll never have to think about that ever again.
> On 7 Apr 2020, at 20:23, Joe Darcy wrote:
>
> Hi Pavel,
>
> Looks fine in general, assuming the change to Class.java renders correctly in
> output.
>
> Thanks,
>
> -Joe
>
> On 4/7/2020 8:28 AM, Pavel
mark that starts a new line, a compound hyphenated word having a newline
character after a hyphen, or a {@code} tag whose contents span multiple lines.
-Pavel
> On 7 Apr 2020, at 17:59, Jonathan Gibbons wrote:
>
>
> On 4/7/20 8:28 AM, Pavel Rappo wrote:
>> Some of the cases this
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8224612:
http://cr.openjdk.java.net/~prappo/8224612/webrev.00/
-Pavel
Hello,
Please review the below change for
https://bugs.openjdk.java.net/browse/JDK-8243318:
diff --git a/test/langtools/jdk/javadoc/tool/8224612/OptionsTest.java
b/test/langtools/jdk/javadoc/tool/8224612/OptionsTest.java
--- a/test/langtools/jdk/javadoc/tool/8224612/OptionsTest.java
+++ b/test/
Hi Jon,
That's really good news for doc-comment writers! Many thanks for doing that.
I'm not an expert in com.sun.tools.javac.parser.DocCommentParser, but that
change looks pretty straightforward. I have a couple of comments though.
1. We should check that this change passes the tests yet leave
> On 23 Apr 2020, at 00:47, Jonathan Gibbons
> wrote:
>
>
> On 4/22/20 2:35 PM, Pavel Rappo wrote:
>> 1. We should check that this change passes the tests yet leaves the OpenJDK
>> API documentation unaffected. The documentation shouldn't change, nor do I
&
s that problem, so it remains unsolved, for now. I have no
>> suggestions for anything we can use, other than to manually inspect pages.
>>
>> -- Jon
>>
>> On 4/22/20 2:35 PM, Pavel Rappo wrote:
>>> Hi Jon,
>>>
>>> That's really g
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8224613
http://cr.openjdk.java.net/~prappo/8224613/webrev.00/
This addresses a scenario in which a doclet failure was previously overlooked.
More specifically, if a doclet returned false after processing one or more
Looks good.
> On 22 Apr 2020, at 13:46, Hannes Wallnoefer
> wrote:
>
> http://cr.openjdk.java.net/~hannesw/8243388/api.00/
emove a new properties would be even better. Best of all would be
> to be able to pass a configured instance of a doclet into JavadocTester and
> from there into an instance of the javadoc tool via its API ... but that last
> step is not yet available.
>
> -- Jon
>
>
The issue:
https://bugs.openjdk.java.net/browse/JDK-8232447
The more I think about this issue, the less I feel like solving it. On the one
hand, that problem is more complicated than it looks. On the other hand,
solving that problem doesn’t seem to be that important since it’s about making
specs/javadoc/doc-comment-spec.html
> $.02, Roger
>
>
> On 5/13/20 12:20 PM, Jonathan Gibbons wrote:
>> Pavel,
>>
>> Good write up. You should link to this from 8232447.
>>
>> -- Jon
>>
>> On 5/13/20 7:44 AM, Pavel Rappo wrote:
>>
020, at 20:01, Jonathan Gibbons
> wrote:
>
>
> On 5/13/20 11:41 AM, Pavel Rappo wrote:
>> Thanks for chiming in, Roger.
>>
>>> On 13 May 2020, at 18:30, Roger Riggs wrote:
>>>
>>> Hi,
>>>
>>> The first sentence is not just
Thanks.
> -- Jon
>
> On 5/13/20 1:49 PM, Pavel Rappo wrote:
>> Jon, here's an idea to ponder. A spin-off of the issue in question. What if
>> we could mitigate the shortcomings of the {@summary} tag by allowing it to
>> be a block tag too? I mean can we make it bimoda
t @param and @return are in the order
opposite to that of their source code counterparts.
We could have a @body tag, but that's a step too far and I'm not suggesting
that. The world these days seems to be going the opposite direction anyway,
from markup to markdown.
-Pavel
> On 5/13
uce a variant form that is likely open to (accidental?) misuse.
>
> If we start going down the road of a style-checker in @doclint, or maybe even
> without that, we could impose a rule that the `{@summary}` tag must be the
> first non-whitespace content.
>
> -- Jon
>
>
> On 14 May 2020, at 22:22, Jonathan Gibbons
> wrote:
>
> On 5/14/20 1:12 PM, Pavel Rappo wrote:
>>> On 14 May 2020, at 20:46, Jonathan Gibbons
>>> wrote:
>>>
>>> OK, but I'm still wondering why it is better to use a block tag for
&g
Looks good to me.
-Pavel
> On 23 Apr 2020, at 23:15, Jonathan Gibbons
> wrote:
>
> Please review a small fix to address an omission in the command-line help
> output generated by `javadoc --help`.
>
> The text that is generated is the same as that for javac, which incidentally,
> uses the sam
1 - 100 of 642 matches
Mail list logo
