as {@link ErroneousTree}.
*/
protected DCTree inlineTag() {
> On 18 Aug 2020, at 12:03, Pavel Rappo wrote:
>
> Hello,
>
> Please review the below inline patch for
> https://bugs.openjdk.java.net/browse/JDK-8251939. Although this patch
> modifies the wording
Hello,
Please review the below inline patch for
https://bugs.openjdk.java.net/browse/JDK-8251939. Although this patch modifies
the wording of two public APIs, I don't think it requires a CSR for either of
them.
Thanks,
-Pavel
diff --git
15:28, Jonathan Gibbons
> wrote:
>
> I've read your responses, which all look OK.
>
> I'll give the webrev a look as well.
>
> -- Jon
>
> On 8/17/20 5:30 AM, Pavel Rappo wrote:
>> Thanks for having a good look at it, Jon. My replies are inline.
>>
>
I forgot to add the link to the new webrev. Here it is:
http://cr.openjdk.java.net/~prappo/8251550/webrev.01/
> On 17 Aug 2020, at 13:30, Pavel Rappo wrote:
>
> Thanks for having a good look at it, Jon. My replies are inline.
>
>> On 14 Aug 2020, at 17:49, Jonathan
Thanks for having a good look at it, Jon. My replies are inline.
> On 14 Aug 2020, at 17:49, Jonathan Gibbons
> wrote:
>
> Good cleanup.
>
> Some systemic changes needed. Details below.
>
> -- Jon
>
> On 8/13/20 11:48 AM, Pavel Rappo wrote:
>> Hello,
&
Hello,
Please review the below change for
https://bugs.openjdk.java.net/browse/JDK-8251550
http://cr.openjdk.java.net/~prappo/8251550/webrev.00/
This represents squashed commits that have accumulated in my git branch. Since
the changeset has started to look dangerously big, I decided not to
Hannes,
I verified that your links worked on macOS versions of Chrome, Firefox, and
Edge.
Looks good to me.
-Pavel
> On 30 Jul 2020, at 12:07, Hannes Wallnoefer
> wrote:
>
> Please review:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8250779
> Webrev:
comparison. Although string
comparison is very flexible, it's a maintenance nightmare. This and some other
situations suggest we should make test assertions using higher-level primitives.
-Pavel
> On 30 Jul 2020, at 08:59, Hannes Wallnoefer
> wrote:
>
> Thanks, Pavel!
>
>
Thanks for doing this.
It seems possible for an empty list of parameters "()" to be of one style,
while a non-empty list to be of another: AbstractMemberWriter.java:689:694
If so, should we fix that too?
-Pavel
> On 28 Jul 2020, at 13:45, Hannes Wallnoefer
> wrote:
>
> Please review:
>
>
Jon,
This looks good.
On a related note. It looks like
System.getProperty("java.specification.version") yields the same value as
String.valueOf(Runtime.version().feature()).
> On 1 Jul 2020, at 01:22, Jonathan Gibbons wrote:
>
> Please review an update to the JDK 16 part of the issues
ocumentation and tracking only, and
> has no functional significance.
>
> In this case, we could use JDK-8248417 which is the issue that describes the
> upcoming test failure, and which will provide the fix for the test.
>
> -- Jon
>
> On 6/29/20 11:54 AM, Pavel Rappo w
Jon,
I rarely problem-list tests. Thus, I'm not sure about the semantics of an issue
mentioned in a problem list entry. To get some insight I looked at other
entries in that ProblemList.txt. The entries from javac, javap, and sjavac I
looked at refer to issues that describe *failures* of the
Jon,
Consider retaining that example string with pre-release information in the doc
comment for Versions#shortVersionStringOf(): "15-internal"; I think this is
useful for illustrative purposes.
Other than that, those patches look good. Thanks.
-Pavel
> On 26 Jun 2020, at 23:04, Jonathan
re are bigger fish to fry, lower-hanging fruit on
> the tree that deserve our attention.
Understood.
>
> -- Jon
>
>
> On 6/25/20 11:27 AM, Pavel Rappo wrote:
>>> On 24 Jun 2020, at 15:28, Jonathan Gibbons
>>> wrote:
>>>
>>> Yes, it's a
: A to B
(java.nio.file.FileAlreadyExistsException: B)
Error copying: A to B
(java.nio.file.FileSystemException: B: Operation not permitted)
-Pavel
> -- Jon
>
> On 6/24/20 5:19 AM, Pavel Rappo wrote:
>> Jon,
>>
>> Consider deleting that ent
Jon,
Consider deleting that entry in ProblemList.txt instead of commenting it out.
Otherwise, the change looks good.
***
That change reminded me of a question I had: do we really need to split I/O
errors into "read" and "write" errors and associate filenames with I/O errors
on the Java
Looks good to me.
> On 23 Jun 2020, at 01:09, Jonathan Gibbons
> wrote:
>
> Hi Pavel,
>
> Thanks for the comments/questions.
>
> On 6/22/20 6:17 AM, Pavel Rappo wrote:
>> Jon,
>>
>> 1. Should we refine this wording to reflect the change?
>
Jon,
1. Should we refine this wording to reflect the change?
dc.no.summary.or.caption.for.table=no summary or caption for table
2. Does it make sense to test all the possibilities? Currently our tests cover
50% of that space.
tested|caption|summary|role
One can invoke DocLint in several different ways. Depending on the way they
choose, the behaviour will slightly differ.
To understand what happens, I need to know how you invoke DocLint. Would you be
able to provide the exact command lines or the code snippets (if you invoke
DocLint
, that shouldn't affect us reporting these messages "correctly".
>
> More answers inline below.
>
> -- Jon
>
>
> On 6/18/20 7:20 AM, Pavel Rappo wrote:
>> [This is not a review.]
>>
>> I want to make sure that we are doing the right thing.
>&
> sentence or
> paragraph.
>
> -- Jon
>
> On 6/19/20 6:21 AM, Pavel Rappo wrote:
>> Hello,
>>
>> Please review the below change for
>> https://bugs.openjdk.java.net/browse/JDK-8247780
>>
>> ---
>> $ hg diff --g
Hello,
Please review the below change for
https://bugs.openjdk.java.net/browse/JDK-8247780
---
$ hg diff --git
diff --git
a/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
Jon, that looks good. Please do not forget to apply the change we discussed
off-line before pushing. That change treats low sensitivity of the
"test/langtools/jdk/javadoc/doclet/testPackageHtml/TestPackageHtml.java" test.
Consider this reply as both +1 and a friendly reminder to fix the test.
[This is not a review.]
I want to make sure that we are doing the right thing.
Looking for definitions of doclint check groups, I found two relevant
documents: the man page for javadoc(1) and JEP 172: DocLint. After skimming
through the man page and the JEP, I can see the reasons for both
> On 17 Jun 2020, at 19:19, Jonathan Gibbons
> wrote:
>
> Please review some updates to the doc comments in JavadocTester,
> to better document the use of the starting/pass/fail methods.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8247760
> Webrev:
athan Gibbons
> wrote:
>
> Pavel,
>
> It's `noreg-impractical` to test cross version functionality, but should
> there be a test for the "same-version" functionality. There may be a suitable
> test already, in which case, it may be enough to add the bug number
That updated webrev looks good.
> On 17 Jun 2020, at 15:37, Jonathan Gibbons
> wrote:
>
> I have posted the correct webrev posted for this bug and URL.
>
> -- Jon
>
> On 6/17/20 6:18 AM, Hannes Wallnoefer wrote:
>> Hi Jon,
>>
>> The URL for the webrev looks correct, but it contains the
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8246078
http://cr.openjdk.java.net/~prappo/8246078/webrev.00/
Note: That bug affects those who run Javadoc as a Java application rather than
as a tool; and only on a JVM from a Platform of a version different than
Replying to Jon's email rather than to Hannes's to acknowledge that I have had
a chance to read both.
Many thanks for doing this, Hannes. This is certainly a big improvement as it
addresses the issue of having no UI feedback in case of slow connections. I'd
say that this change solves 80% of
Jon,
Having in mind my extremely limited experience with jdk.compiler, the code
change looks okay. However, the test could be even better: it would be cleaner
if the test were built around actual tags rather than tag trees. Otherwise, the
proposed test is of "grey-box" kind as it uses the fact
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8245981
http://cr.openjdk.java.net/~prappo/8245981/webrev.00/
This upgrades the jQuery library to the latest release 3.5.1. I've checked that
the API documentation for JDK continues to work as expected on macOS
t; On 5/28/20 7:08 AM, Pavel Rappo wrote:
>> 1. I don't understand why JDK-8222548 renamed "jquery.js" to
>> "jquery-3.4.1.js". Unless necessary, things like this introduce unneeded
>> churn to the codebase. It's much cleaner to change just the contents
> 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
>>
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 5/
ks.
> -- 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 bimodal?
>>
doc/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:
>>&g
perties 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
>
> On 4/29/20 11
Looks good.
> On 22 Apr 2020, at 13:46, Hannes Wallnoefer
> wrote:
>
> http://cr.openjdk.java.net/~hannesw/8243388/api.00/
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
t 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 good news f
> 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
>&g
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
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
+++
Hello,
Please review the change for https://bugs.openjdk.java.net/browse/JDK-8224612:
http://cr.openjdk.java.net/~prappo/8224612/webrev.00/
-Pavel
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 patch
e'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
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/java/lang/invoke/VarHandle.html
>
> [2]
> https://docs.orac
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
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 question. Tha
Hi Jon,
The proposed patch does fix the issue in question. That said, I noticed one more
visual difference between the current L 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
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
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
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
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
s 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 Rappo wro
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
; 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://cr.openjdk.java
el,
>
> 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/20 7:
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'
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
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
Looks good to me.
> On 5 Mar 2020, at 02:05, Jonathan Gibbons wrote:
>
> http://cr.openjdk.java.net/~jjg/8240555/webrev.00/
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
>> "testExternal
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/
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
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.
> 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
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,
>
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
xBuilder 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, Pavel Rappo wrote:
acter(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
>
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,
>>
>> Please review the change for
&g
> 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
> 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 a
>
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
gt; 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 index files" fea
> 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
>> interchangeable (e.g. 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
ot;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 tad b
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.
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
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
-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/
>>
>> Th
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:
>> 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
ious-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,
>>
>> Please review the change for
>> https://bugs.openjdk.java.net/browse/JDK-8237
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}
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,
> 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
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
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
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
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
-- 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 change in a nutshell, it
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
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!
ass 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 checking.
>
> --
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
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 :
>>
>>
> 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.
501 - 600 of 618 matches
Mail list logo
