Re: RFR: JDK-8252717: Integrate/merge legacy standard doclet diagnostics and doclint
On Thu, 2 Jun 2022 20:59:26 GMT, Jonathan Gibbons wrote: > Please review a moderate change to enable (most) doclet warnings even if > doclint is enabled. > > Since the introduction of doclint, there was some (small) overlap between the > small set of warnings generated by the doclet and the new larger set of > diagnostics that could be generated by doclint. The solution, until now, has > been to disable doclet warnings when doclint is enabled. But, the sets do not > overlap, and the policy has inappropriately suppressed some warnings and > inhibited the generation of new warnings by the doclet that could only be > done by the doclet, and not doclint. > > One notable group of warnings that has been inappropriately suppressed is the > warnings generated by using the `-serial warn` option. > > The fundamental core of the change is to remove the conditional checks in the > doclet `Messages.java`, which would suppress messages when doclint was > enabled. A consequence is that some specific messages have to disabled if > they are duplicate checks if doclint is enabled. (The messages cannot be > removed altogether because doclint might _not_ be enabled.) A test is added > to verify that either one message or the other is generated, but never both. > > As previously noted, an issue with the earlier policy is that warnings > generated by using the `-serial warn` option were inappropriately suppressed, > and this change fixes that ... revealing a number of latent warnings in the > JDK API that need to be addressed. The short term fix here is to temporarily > remove the use of the `-serialwarn` option. See > [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749). Looks good. > I did a visual inspection over the Checker class. > The test is set up to be a framework to accommodate new cases if any should > arise. This is good. It would be even better if we had a mechanism to reduce risk of diagnostic duplication in the future. I don't have any concrete proposal, but unique internal error codes shared between doclint and doclet come to mind. - Marked as reviewed by prappo (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9006
Re: RFR: JDK-8252717: Integrate/merge legacy standard doclet diagnostics and doclint
On Thu, 2 Jun 2022 20:59:26 GMT, Jonathan Gibbons wrote: > Please review a moderate change to enable (most) doclet warnings even if > doclint is enabled. > > Since the introduction of doclint, there was some (small) overlap between the > small set of warnings generated by the doclet and the new larger set of > diagnostics that could be generated by doclint. The solution, until now, has > been to disable doclet warnings when doclint is enabled. But, the sets do not > overlap, and the policy has inappropriately suppressed some warnings and > inhibited the generation of new warnings by the doclet that could only be > done by the doclet, and not doclint. > > One notable group of warnings that has been inappropriately suppressed is the > warnings generated by using the `-serial warn` option. > > The fundamental core of the change is to remove the conditional checks in the > doclet `Messages.java`, which would suppress messages when doclint was > enabled. A consequence is that some specific messages have to disabled if > they are duplicate checks if doclint is enabled. (The messages cannot be > removed altogether because doclint might _not_ be enabled.) A test is added > to verify that either one message or the other is generated, but never both. > > As previously noted, an issue with the earlier policy is that warnings > generated by using the `-serial warn` option were inappropriately suppressed, > and this change fixes that ... revealing a number of latent warnings in the > JDK API that need to be addressed. The short term fix here is to temporarily > remove the use of the `-serialwarn` option. See > [JDK-8287749](https://bugs.openjdk.java.net/browse/JDK-8287749). > Since the introduction of doclint, there was some (small) overlap between the > small set ... and the new larger set ... But, the sets do not overlap Do or do they not overlap? :) > the policy has inappropriately suppressed some warnings and inhibited the > generation of new warnings What's the difference between "suppressed" and "inhibited" here? Generally, how can we be sure that we haven't missed any double-reported cases? test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java line 136: > 134: var doclintResult = new Result(Exit.OK, "C.java:8: warning: > @param \"x\" has already been specified"); > 135: var docletResult = new Result(Exit.OK, "C.java:8: warning: > Parameter \"x\" is documented more than once."); > 136: Both are warnings, hence two `Exit.OK` results; I see. test/langtools/jdk/javadoc/doclet/testDoclintDocletMessages/TestDocLintDocletMessages.java line 190: > 188: checkExit(expect.exit); > 189: > 190: checkOutput(Output.OUT, true,expect.message); Add whitespace after `true,` - PR: https://git.openjdk.java.net/jdk/pull/9006
Re: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI [v2]
On Wed, 27 Oct 2021 17:15:23 GMT, Jonathan Gibbons wrote: >> Hannes Wallnöfer has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update copyright years > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java > line 396: > >> 394: .put(HtmlAttr.DATA_COPIED, copiedText)); >> 395: HtmlTree pre = new HtmlTree(TagName.PRE) >> 396: .setStyle(HtmlStyle.snippet); > > This should be updated (later) to follow the HTML recommendations. As you know, the relevant issue was created some time ago: JDK-8275788. - PR: https://git.openjdk.java.net/jdk/pull/6011
Re: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI [v2]
On Wed, 27 Oct 2021 17:04:53 GMT, Jonathan Gibbons wrote: >> I think this change is OK for now. We can make it more restrictive later if >> it becomes a problem. I tried to come up with a short explanatory comment, >> but couldn't find one I was satisfied with. > > While maybe uncommon and maybe not necessary, it is not bad HTML (is it?) to > have an empty fragment. > Verified: > * https://en.wikipedia.org/wiki/URI_fragment > * https://datatracker.ietf.org/doc/html/rfc3986#section-3.5 What was the purpose of that check added in JDK-8216319 in the first place? If the check is irrelevant, we should remove it. - PR: https://git.openjdk.java.net/jdk/pull/6011
Re: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI [v2]
On Wed, 20 Oct 2021 14:30:04 GMT, Pavel Rappo wrote: >> Yes, they are localized. Good question, I do believe tests are run with >> fixed en/US locale, but I'm not absolutely sure. > > I've traced the execution of a local jtreg run with a debugger and examined > the respective `jtr` file. Here is what I saw. The locale that the javadoc > under test uses is that of returned by java.util.Locale.getDefault(). This > happens because neither of the three pieces -- jtreg, JavadocTester, or > TestSnippetTag -- passes `-locale` to javadoc. > > Now I begin to wonder: how come we don't see failures on CI builds? Are we > lucky and all the machines on which javadoc tests run use variants of English > locale? Do we not have other tests where we hard-code English string > variants? Is there something that I don't see? You don't have to do anything about locales in this PR; this part is fine as it is. I filed a bug, JDK-8275727, to address this issue at mass. It looks like almost half of javadoc tests have a similar issue. - PR: https://git.openjdk.java.net/jdk/pull/6011
Re: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI [v2]
On Wed, 20 Oct 2021 10:18:24 GMT, Hannes Wallnöfer wrote:
>> test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java line 354:
>>
>>> 352: void addReference(String name, Path from, int line) {
>>> 353: if (checked) {
>>> 354: if (name != null && !name.isEmpty()) {
>>
>> I wonder if we should make this check more specific so as to allow only the
>> snippet copy-to-clipboard link.
>
> I think this should be ok for the general case. Linking to "#" (i.e. empty
> fragment) is common practice for links that trigger script functions.
What I mean is that the amended test will now pass for a URL which has an empty
fragment but is not a "button".
-
PR: https://git.openjdk.java.net/jdk/pull/6011
Re: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI [v2]
On Wed, 20 Oct 2021 10:15:39 GMT, Hannes Wallnöfer wrote: >> test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line >> 214: >> >>> 212: >> class="element-name">case%s() >>> 213: >>> 214: >> class="snippet-copy" onclick="cop\ >> >> I'm sorry for hard-coding the snippet HTML output; I should've encapsulated >> it instead. Now every change to the HTML structure ripples through the >> tests. I'll work on improving that, I promise. >> >> Separately. Aren't these "Copy" and "Copied!" strings localized? What >> happens if this test is run on some other locale? > > Yes, they are localized. Good question, I do believe tests are run with fixed > en/US locale, but I'm not absolutely sure. I've traced the execution of a local jtreg run with a debugger and examined the respective `jtr` file. Here is what I saw. The locale that the javadoc under test uses is that of returned by java.util.Locale.getDefault(). This happens because neither of the three pieces -- jtreg, JavadocTester, or TestSnippetTag -- passes `-locale` to javadoc. Now I begin to wonder: how come we don't see failures on CI builds? Are we lucky and all the machines on which javadoc tests run use variants of English locale? Do we not have other tests where we hard-code English string variants? Is there something that I don't see? - PR: https://git.openjdk.java.net/jdk/pull/6011
Re: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI
On Tue, 19 Oct 2021 13:51:03 GMT, Hannes Wallnöfer wrote:
> Please review a change to add a copy-to-clipboard feature to snippets. I took
> special care to make the feature usable on mobile devices. Sample output can
> be viewed and tested here:
>
> http://cr.openjdk.java.net/~hannesw/8275406/api.00/java.base/java/lang/Throwable.html#printStackTrace()
The UI functionality looks good. Update the copyright years in `Java.gmk`,
`LinkChecker.java` and maybe other files.
test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 214:
> 212: case%s()
> 213:
> 214: class="snippet-copy" onclick="cop\
I'm sorry for hard-coding the snippet HTML output; I should've encapsulated it
instead. Now every change to the HTML structure ripples through the tests. I'll
work on improving that, I promise.
Separately. Aren't these "Copy" and "Copied!" strings localized? What happens
if this test is run on some other locale?
test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java line 354:
> 352: void addReference(String name, Path from, int line) {
> 353: if (checked) {
> 354: if (name != null && !name.isEmpty()) {
I wonder if we should make this check more specific so as to allow only the
snippet copy-to-clipboard link.
test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java line 371:
> 369: void check() {
> 370: map.forEach((name, id) -> {
> 371: if (name != null && !name.isEmpty() && !id.declared) {
Ditto.
-
Changes requested by prappo (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6011
Re: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v2]
On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons wrote:
>> This introduces support for a new `@spec` tag 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 `label` in the generated docs.
>>
>> As a block tag, the format is simply
>>
>> @spec url label
>>
>> which is handled in a manner analogous to
>>
>> @see label
>>
>> 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 to `DocCommentParser` are
>> 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.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 11 commits:
>
> - Fix merge issues; review feedback
> - Merge with master
> - allow rich content in createAnchorAndSearchIndex
> - update Docs.gmk to stop disabling spec tag
> - fix TestSpecTag.testEncodedURI
> - fix tests
> - remove support to workaround legacy @spec tag
> - Merge remote-tracking branch 'upstream/master' into new-spec-tag
> - fix trailing whitespace in test
> - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
> - ... and 1 more:
> https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9
1. Thanks for incorporating my previous offline feedback.
2. 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!
3. There should be a corresponding but separate change to "Documentation
Comment Specification for the Standard Doclet".
4. Can we use this new `@since` tag to refer to the spec at
`com/sun/tools/javac/parser/DocCommentParser.java:1116`?
5. Should we specify in `com.sun.source.doctree.SpecTree` that both `url` and
`label` parts are mandatory?
6. `DCSpec extends DCEndPosTree`, sigh... Although that is not a public API,
this design suggests we could improve that abstraction sometime later.
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java
line 1104:
> 1102:
> 1103: DCTree parse(int pos, Kind kind) throws ParseException {
> 1104: if (kind != this.kind && this.kind != Kind.EITHER) {
This condition looks right, but shouldn't we add another one to guard against
accidental passing of `kind == EITHER`?
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
line 306:
> 304: * The {@code ref} argument will be URL-encoded for use as the
> attribute value.
> 305: *
> 306: * @param ref the value for the {@code href} attribute}
Since you are here, could you please remove that trailing `}`?
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
line 322:
> 320: * {@link URI#toASCIIString() converted} to ASCII for use as the
> attribute value.
> 321: *
> 322: * @param ref the value for the {@code href} attribute}
One more, perhaps copy-pasted, trailing `}`.
test/langtools/tools/javac/diags/examples/NoLabel.java line 2:
> 1: /*
> 2: * Copyright (c) 2012, 2020 Oracle and/or its affiliates. All rights
> reserved.
Should be:
`Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.`
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
line 266:
> 264: }
> 265:
> 266: String textOf(List trees) {
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: `.
src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 81:
> 79: return list.stream().allMatch(DCTree::isBlank);
> 80: }
> 81:
Adding these two methods **here** might be overkill.
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java
line 737:
> 735:
> 736: for (Taglet t : taglets) {
> 737: String name = t.isBlockTag() ? "@" + t.getName() : "{@" +
> t.getName() + "}";
Out of curiosity, why did you flip that?
-
Changes requested by prappo (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/790
Re: RFR: JDK-6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec) [v2]
On Wed, 4 Nov 2020 20:57:06 GMT, Jonathan Gibbons wrote:
>> This introduces support for a new `@spec` tag 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 `label` in the generated docs.
>>
>> As a block tag, the format is simply
>>
>> @spec url label
>>
>> which is handled in a manner analogous to
>>
>> @see label
>>
>> 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 to `DocCommentParser` are
>> 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.
>
> Jonathan Gibbons has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 11 commits:
>
> - Fix merge issues; review feedback
> - Merge with master
> - allow rich content in createAnchorAndSearchIndex
> - update Docs.gmk to stop disabling spec tag
> - fix TestSpecTag.testEncodedURI
> - fix tests
> - remove support to workaround legacy @spec tag
> - Merge remote-tracking branch 'upstream/master' into new-spec-tag
> - fix trailing whitespace in test
> - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
> - ... and 1 more:
> https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9
src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 309:
> 307: * Creates a new {@code SpecTree} object, to represent a {@code
> @spec} tag.
> 308: *
> 309: * @param inline whether this is instance is an inline tag
Should be:
`* @param inline whether this instance is an inline tag`
-
PR: https://git.openjdk.java.net/jdk/pull/790
Re: RFR docs 8240777: Update all nroff manpages for JDK 15 release
Lance, Those are good questions that show that there's value in seeing all the changes to the man pages at once. Let's ask experts in the corresponding areas. -Pavel > On 24 Jul 2020, at 11:28, Lance @ Oracle wrote: > > Hi PaveL, > > I made a pass through your web rev and had a couple quick questions: > > Is there a reason we use macOS in some places and OS X in others as I would > think we should be consistent throughout. > > The notes regarding Jdk 10 that talk about adding support for the attach api > that are being removed I was wondering if the information should be kept (or > is this no longer valid) and just remove the jdk 10 specific reference? > > Best, > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > lance.ander...@oracle.com > Sent from my iPad > >> On Jul 24, 2020, at 5:34 AM, Pavel Rappo wrote: >> >> Please review the updated webrev: >> >>http://cr.openjdk.java.net/~prappo/8240777/webrev.01/ >> >>> On 24 Jun 2020, at 10:48, David Holmes wrote: >>> >>> Hi Pavel, >>> >>> On 24/06/2020 7:35 pm, Pavel Rappo wrote: >>>> David, >>>> I'm planning to review and push manpage changes that will have accumulate >>>> by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date >>>> could be performed by the component owners themselves; I think this is >>>> reasonable, would you agree? >>> >>> Okay sounds reasonable. >>> >>> Thanks, >>> David >>> >>>> -Pavel >>>>> On 11 Jun 2020, at 03:42, David Holmes wrote: >>>>> >>>>> Hi Pavel, >>>>> >>>>> This issue can't be closed out yet as we are only at ramp down phase 1. >>>>> There are still documentation changes coming that will need the manpages >>>>> to be updated again before JDK 15 is released. >>>>> >>>>> David >>>>> >>>>> On 11/06/2020 5:21 am, Pavel Rappo wrote: >>>>>> Hello, >>>>>> Please review the change for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8240777 >>>>>> http://cr.openjdk.java.net/~prappo/8240777/webrev.00/ >>>>>> This is supposed to be similar to the previous iteration: >>>>>> >>>>>> https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html >>>>>> The only difference is that the copyright years are more accurate as >>>>>> they are restored from the original man pages. >>>>>> -Pavel >>
Re: RFR docs 8240777: Update all nroff manpages for JDK 15 release
Please review the updated webrev: http://cr.openjdk.java.net/~prappo/8240777/webrev.01/ > On 24 Jun 2020, at 10:48, David Holmes wrote: > > Hi Pavel, > > On 24/06/2020 7:35 pm, Pavel Rappo wrote: >> David, >> I'm planning to review and push manpage changes that will have accumulate by >> Rampdown Phase Two, which is on 2020-07-16. Any updates after that date >> could be performed by the component owners themselves; I think this is >> reasonable, would you agree? > > Okay sounds reasonable. > > Thanks, > David > >> -Pavel >>> On 11 Jun 2020, at 03:42, David Holmes wrote: >>> >>> Hi Pavel, >>> >>> This issue can't be closed out yet as we are only at ramp down phase 1. >>> There are still documentation changes coming that will need the manpages to >>> be updated again before JDK 15 is released. >>> >>> David >>> >>> On 11/06/2020 5:21 am, Pavel Rappo wrote: >>>> Hello, >>>> Please review the change for >>>> https://bugs.openjdk.java.net/browse/JDK-8240777 >>>> http://cr.openjdk.java.net/~prappo/8240777/webrev.00/ >>>> This is supposed to be similar to the previous iteration: >>>> >>>> https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html >>>> The only difference is that the copyright years are more accurate as they >>>> are restored from the original man pages. >>>> -Pavel
Re: RFR docs 8240777: Update all nroff manpages for JDK 15 release
David, I'm planning to review and push manpage changes that will have accumulate by Rampdown Phase Two, which is on 2020-07-16. Any updates after that date could be performed by the component owners themselves; I think this is reasonable, would you agree? -Pavel > On 11 Jun 2020, at 03:42, David Holmes wrote: > > Hi Pavel, > > This issue can't be closed out yet as we are only at ramp down phase 1. There > are still documentation changes coming that will need the manpages to be > updated again before JDK 15 is released. > > David > > On 11/06/2020 5:21 am, Pavel Rappo wrote: >> Hello, >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777 >> http://cr.openjdk.java.net/~prappo/8240777/webrev.00/ >> This is supposed to be similar to the previous iteration: >> https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html >> The only difference is that the copyright years are more accurate as they >> are restored from the original man pages. >> -Pavel
RFR [15] 8247936: Fix typos in man pages
Hello, Please review the below change for https://bugs.openjdk.java.net/browse/JDK-8247936 --- diff --git a/closed/src/java.base/share/man/java.md b/closed/src/java.base/share/man/java.md --- a/closed/src/java.base/share/man/java.md +++ b/closed/src/java.base/share/man/java.md @@ -2691,7 +2691,7 @@ : Sets the allocation spike tolerance for ZGC. By default, this option is set to 2.0. This factor describes the level of allocation spikes to expect. For example, using a factor of 3.0 means the current allocation rate can -be expected to tripple at any time. +be expected to triple at any time. `-XX:ZCollectionInterval`=*seconds* : Sets the maximum interval (in seconds) between two GC cycles when using @@ -2700,7 +2700,7 @@ `-XX:ZFragmentationLimit`=*percent* : Sets the maximum acceptable heap fragmentation (in percent) for ZGC. By default, this option is set to 25. Using a lower value will cause the -heap to be compacted more agressively, to reclaim more memory at the cost +heap to be compacted more aggressively, to reclaim more memory at the cost of using more CPU time. `-XX:+ZProactive` diff --git a/closed/src/java.base/share/specs/jar/jar.md b/closed/src/java.base/share/specs/jar/jar.md --- a/closed/src/java.base/share/specs/jar/jar.md +++ b/closed/src/java.base/share/specs/jar/jar.md @@ -605,7 +605,7 @@ Digital signature files for signature algorithms not listed above must reside in the `META-INF` directory and have the prefix "`SIG-`". The -corresonding signature file (`.SF` file) must also have the same prefix. +corresponding signature file (`.SF` file) must also have the same prefix. For those formats that do not support external signed data, the file shall consist of a signed copy of the `.SF` file. Thus some data may be diff --git a/closed/src/jdk.jcmd/share/man/jcmd.md b/closed/src/jdk.jcmd/share/man/jcmd.md --- a/closed/src/jdk.jcmd/share/man/jcmd.md +++ b/closed/src/jdk.jcmd/share/man/jcmd.md @@ -629,7 +629,7 @@ `VM.log` \[*options*\] : Lists current log configuration, enables/disables/configures a log output, -or ro tates all logs. +or rotates all logs. Impact: Low diff --git a/closed/src/jdk.jdwp.agent/share/specs/jdwp/jdwp-transport.md b/closed/src/jdk.jdwp.agent/share/specs/jdwp/jdwp-transport.md --- a/closed/src/jdk.jdwp.agent/share/specs/jdwp/jdwp-transport.md +++ b/closed/src/jdk.jdwp.agent/share/specs/jdwp/jdwp-transport.md @@ -38,7 +38,7 @@ value other than `JDWPTRANSPORT_ERROR_NONE`) then a string representing the error can be subsequently obtained through a call to the jdwpTransport function `GetLastError`. Errors are recorded on a per-thread basis. The `GetLastError` -function will return a string represetning the last error that was encountered +function will return a string representing the last error that was encountered by the current thread only. ## Developing a Transport implementation @@ -90,7 +90,7 @@ The function table has two entries. The `alloc` function allocates an area of memory. It has a single argument to specify the number of bytes to allocate. It -returns a pointer to the begining of the allocated memory, or NULL if the +returns a pointer to the beginning of the allocated memory, or NULL if the memory request cannot be honored. If the number of bytes requested is zero then NULL is returned. The `free` function deallocates an area of memory that was previously allocated using the `alloc` function. --- Since we are waiting for the remaining updates to man pages for JDK 15 [1], I think now is a good opportunity to fix some typos. Regarding that change above. There's one typo could be fixed by rephrasing. Instead of fixing like this: -be expected to tripple at any time. +be expected to triple at any time. It could be alternatively fixed like this: -be expected to tripple at any time. +be expected to increase threefold at any time. -Pavel [1] https://mail.openjdk.java.net/pipermail/build-dev/2020-June/027674.html
RFR docs 8240777: Update all nroff manpages for JDK 15 release
Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8240777 http://cr.openjdk.java.net/~prappo/8240777/webrev.00/ This is supposed to be similar to the previous iteration: https://mail.openjdk.java.net/pipermail/build-dev/2020-January/026578.html The only difference is that the copyright years are more accurate as they are restored from the original man pages. -Pavel
Re: Build support for JDK-8044627
Thanks Erik! -Pavel On 15 Oct 2014, at 11:40, Erik Joelsson erik.joels...@oracle.com wrote: Hello, I have managed to come up with this solution for jdk9/dev. http://cr.openjdk.java.net/~erikj/8044627/webrev.01/ I added a gensrc step for each of the affected modules that simply concatenates the files into the gensrc output dir. The version found there will automatically override the one in the jdk/src. There is an extra complication at the top level as java.corba already had a gensrc step in the corba repo. The proper solution for that part will have to be done in Jigsaw M2, the merge will be hairy. I also had come up with a way to only include one of the files in resources.jar, since the jar command doesn't like duplicate entries. This is a bit of a hack, explicitly excluding 3 of the files, but since resource.jar is going away in M2 anyway, I think it's fine for now. /Erik On 2014-10-14 15:37, Erik Joelsson wrote: Hello Pavel, This will be a bit tricky. Give me a day or two and I will try to come up with something. /Erik On 2014-10-14 15:27, Pavel Rappo wrote: Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Build support for JDK-8044627
Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Re: RFR JDK-8044627: Update JNDI to work with modules
Thanks a lot! -Pavel On 14 Oct 2014, at 15:33, Chris Hegarty chris.hega...@oracle.com wrote: META-INF files in the webrev, two of which are in the wrong location. They are directly under 'META-INF’, where they should all be under ‘META-INF/services’. This is just a note for Pavel, when he follows up later with the addition of these service configuration files, and also to avoid confusion.
