Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words >> with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were >> changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this >> PR. Such changes will be picked up from their upstream sources. > > Brent Christian has updated the pull request incrementally with one > additional commit since the last revision: > > updates, per code review test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45: > 43: SocketChannel client = SocketChannel.open (); > 44: client.connect (new InetSocketAddress > (InetAddress.getLoopbackAddress(), port)); > 45: SocketChannel channel = server.accept (); Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there). - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8247957: remove doclint support for HTML 4 [v2]
On Fri, 11 Dec 2020 06:44:57 GMT, Yoshiki Sato wrote: >> Please make the review non-draft as well > > Thanks for reviewing @jonathan-gibbons > This request should have got changed to "non-draft". > > FYI. all tests in jdk-tier1 are still green with the latest changes. > https://mach5.us.oracle.com/mdash/jobs/yoshiki-jdk-20201211-0555-16616611 This commit includes the changes for 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option The changes presume the changes made by a 8247957. And there is no need to separate them from 8247957, so I would like to pull all changes into this. - PR: https://git.openjdk.java.net/jdk/pull/893
Re: RFR: 8247957: remove doclint support for HTML 4 [v2]
> HTML4 is no longer supported in javadoc. > > doclint needs to drop HTML4 support as well. > The changes consist of: > * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references. > * Sorting out supported tags and attributes in HTML5 (including fix incorrect > permission of valign in TH, TR, TD, THEAD and TBODY) > * Modifying test code and expected outputs to be checked in HTML5 Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision: 8257204 and 8256313 8257204: Remove usage of -Xhtmlversion option from javac 8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option - Changes: - all: https://git.openjdk.java.net/jdk/pull/893/files - new: https://git.openjdk.java.net/jdk/pull/893/files/4b733399..294b3cce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=00-01 Stats: 182 lines in 9 files changed: 0 ins; 71 del; 111 mod Patch: https://git.openjdk.java.net/jdk/pull/893.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893 PR: https://git.openjdk.java.net/jdk/pull/893
Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
> This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: updates, per code review - Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/4efa5d43..29525f05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian wrote: >> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java >> line 152: >> >>> 150: * >>> 151: * Care must be taken when defining such a filter, as defining >>> 152: * an accept-list too restrictive or a too-wide reject-list may >> >> would "an allow-list too restrictive or a reject-list too wide" read better? > > I agree that there is room for improvement here. How about: > "...an allow-list too restrictively, or a reject-list too broadly, may..." > ? That sounds good to me - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang wrote: >> This is part of an effort in the JDK to replace archaic/non-inclusive words >> with more neutral terms (see JDK-8253315 for details). >> >> Here are the changes covering core libraries code and tests. Terms were >> changed as follows: >> 1. grandfathered -> legacy >> 2. blacklist -> filter or reject >> 3. whitelist -> allow or accept >> 4. master -> coordinator >> 5. slave -> worker >> >> Addressing similar issues in upstream 3rd party code is out of scope of this >> PR. Such changes will be picked up from their upstream sources. > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java > line 152: > >> 150: * >> 151: * Care must be taken when defining such a filter, as defining >> 152: * an accept-list too restrictive or a too-wide reject-list may > > would "an allow-list too restrictive or a reject-list too wide" read better? I agree that there is room for improvement here. How about: "...an allow-list too restrictively, or a reject-list too broadly, may..." ? - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Marked as reviewed by joehw (Reviewer).
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
line 135:
> 133: * The pattern must be in same format as used in
> 134: * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135: * It may define an accept-list of permitted classes, a reject-list
> of
should accept-list be allow-list to be consistent with the other two RMI
classes and ObjectInputFilter.Status#ALLOWED?
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
line 152:
> 150: *
> 151: * Care must be taken when defining such a filter, as defining
> 152: * an accept-list too restrictive or a too-wide reject-list may
would "an allow-list too restrictive or a reject-list too wide" read better?
-
PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Marked as reviewed by rriggs (Reviewer).
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
line 135:
> 133: * The pattern must be in same format as used in
> 134: * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135: * It may define an accept-list of permitted classes, a reject-list
> of
accept -> allow for consistency
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java
line 152:
> 150: *
> 151: * Care must be taken when defining such a filter, as defining
> 152: * an accept-list too restrictive or a too-wide reject-list may
accept -> allow for consistency
-
PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote: > This is part of an effort in the JDK to replace archaic/non-inclusive words > with more neutral terms (see JDK-8253315 for details). > > Here are the changes covering core libraries code and tests. Terms were > changed as follows: > 1. grandfathered -> legacy > 2. blacklist -> filter or reject > 3. whitelist -> allow or accept > 4. master -> coordinator > 5. slave -> worker > > Addressing similar issues in upstream 3rd party code is out of scope of this > PR. Such changes will be picked up from their upstream sources. Marked as reviewed by kcr (Author). - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Looks good to me.
test/jdk/java/lang/ClassLoader/Assert.java line 65:
> 63:
> 64: int switchSource = 0;
> 65: if (args.length == 0) { // This is the coordinator version
Extra space between "is" and "the."
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1771
RFR: 8253497: Core Libs Terminology Refresh
This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details). Here are the changes covering core libraries code and tests. Terms were changed as follows: 1. grandfathered -> legacy 2. blacklist -> filter or reject 3. whitelist -> allow or accept 4. master -> coordinator 5. slave -> worker Addressing similar issues in upstream 3rd party code is out of scope of this PR. Such changes will be picked up from their upstream sources. - Commit messages: - Terminology Cleanup - corelibs terminology refresh - bchristi Changes: https://git.openjdk.java.net/jdk/pull/1771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253497 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: [jdk16] RFR: JDK-8247994: Localize javadoc search
On Mon, 14 Dec 2020 09:34:31 GMT, Hannes Wallnöfer wrote:
>> This is for JDK16, as a precursor to fixing JDK-8258002.
>>
>> While it is good to be using localized strings in the generated output, the
>> significance for JDK-8258002 is that the strings are now obtained from a
>> resource file, and not hardcoded in JavaScript file itself.
>>
>> The source file `search.js` is renamed to `search.js.template`, and (unlike
>> other template files) is copied as-is into the generated image. The values
>> in the template are resolved when javadoc is executed, depending on the
>> locale in use at the time. Because of the change in the file's extension,
>> two makefiles are updated to accommodate the new extension: one is for the
>> "interim" javadoc used to generate the API docs; the other is for the
>> primary javadoc in the main JDK image.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java
> line 256:
>
>> 254: sb.append(resources.getText(m.group("key")));
>> 255: } catch (MissingResourceException e) {
>> 256: sb.append(m.group());
>
> Shouldn't we propagate an error here, or issue a warning? If a key is missing
> localized properties the value from default properties should be used, so
> this should never happen, right?
I see the added check for "##REPLACE:" in TestSearch.java will catch that case,
so I guess it's ok.
-
PR: https://git.openjdk.java.net/jdk16/pull/16
Re: [jdk16] RFR: JDK-8247994: Localize javadoc search
On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons wrote:
> This is for JDK16, as a precursor to fixing JDK-8258002.
>
> While it is good to be using localized strings in the generated output, the
> significance for JDK-8258002 is that the strings are now obtained from a
> resource file, and not hardcoded in JavaScript file itself.
>
> The source file `search.js` is renamed to `search.js.template`, and (unlike
> other template files) is copied as-is into the generated image. The values in
> the template are resolved when javadoc is executed, depending on the locale
> in use at the time. Because of the change in the file's extension, two
> makefiles are updated to accommodate the new extension: one is for the
> "interim" javadoc used to generate the API docs; the other is for the primary
> javadoc in the main JDK image.
Looks good in general. `` shouldn't be localized as it is an internal
tag (see inline comment).
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template
line 40:
> 38: var MIN_RESULTS = 3;
> 39: var MAX_RESULTS = 500;
> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##";
`` is not a string that is ever shown to the user, it is what is used
by javadoc to denote the default package (see
`toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't
be localized as that would break behaviour for code in the default package (and
show the localized string as package name, instead of no package name).
src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java
line 256:
> 254: sb.append(resources.getText(m.group("key")));
> 255: } catch (MissingResourceException e) {
> 256: sb.append(m.group());
Shouldn't we propagate an error here, or issue a warning? If a key is missing
localized properties the value from default properties should be used, so this
should never happen, right?
-
Changes requested by hannesw (Reviewer).
PR: https://git.openjdk.java.net/jdk16/pull/16
