Integrated: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI
On Fri, 9 Apr 2021 13:15:16 GMT, Conor Cleary wrote: > ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, > the details of which can be seen in > [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number > JNDI methods under `java.naming` use Anonymous Inner Classes in cases where > only a single object unique to the requirements of the method is used. The > issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one > operation is required. While AICs can be useful for more complex > implementations (using interfaces, multiple methods needed, local fields > etc.), Lambdas are better suited here as they result in a more readable and > concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address > the issues above resulting primarily in more readable/concise code. This pull request has now been integrated. Changeset: 4e90d740 Author:Conor Cleary Committer: Aleksei Efimov URL: https://git.openjdk.java.net/jdk/commit/4e90d740 Stats: 84 lines in 5 files changed: 0 ins; 48 del; 36 mod 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI Reviewed-by: rriggs, dfuchs, aefimov, chegar - PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v3]
> ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, > the details of which can be seen in > [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number > JNDI methods under `java.naming` use Anonymous Inner Classes in cases where > only a single object unique to the requirements of the method is used. The > issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one > operation is required. While AICs can be useful for more complex > implementations (using interfaces, multiple methods needed, local fields > etc.), Lambdas are better suited here as they result in a more readable and > concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address > the issues above resulting primarily in more readable/concise code. Conor Cleary has updated the pull request incrementally with one additional commit since the last revision: 8048199: Cleaner syntak in getContextClassLoader - Changes: - all: https://git.openjdk.java.net/jdk/pull/3416/files - new: https://git.openjdk.java.net/jdk/pull/3416/files/840ea35c..5d6ecd31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3416=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3416=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416 PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2]
On Tue, 13 Apr 2021 09:34:15 GMT, Conor Cleary wrote:
>> src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line
>> 223:
>>
>>> 221: */
>>> 222: private final ClassLoader getContextClassLoader() {
>>> 223: PrivilegedAction pa = () ->
>>> Thread.currentThread().getContextClassLoader();
>>
>> We can use here an instance method reference to beautify code a little bit
>> more:
>> ```PrivilegedAction pa =
>> Thread.currentThread()::getContextClassLoader;```
>
> Good idea, also would fit in with the style of the method just after,
> `priviligedHasNext()` as that also uses a functional interface.
Changes included as described in commit
[5d6ecd3](https://github.com/openjdk/jdk/pull/3416/commits/5d6ecd31eb6ed2a63f17b2e798e83b91cb720075)
-
PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2]
On Mon, 12 Apr 2021 16:44:16 GMT, Aleksei Efimov wrote:
>> Conor Cleary has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update copyright headers
>> - Tidied up lambdas
>
> src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java line 223:
>
>> 221: */
>> 222: private final ClassLoader getContextClassLoader() {
>> 223: PrivilegedAction pa = () ->
>> Thread.currentThread().getContextClassLoader();
>
> We can use here an instance method reference to beautify code a little bit
> more:
> ```PrivilegedAction pa =
> Thread.currentThread()::getContextClassLoader;```
Good idea, also would fit in with the style of the method just after,
`priviligedHasNext()` as that also uses a functional interface.
-
PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2]
On Fri, 9 Apr 2021 16:30:05 GMT, Roger Riggs wrote: >> Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, >> default)` for the `getProperty()` method looks great. >> >> WRT to using it for `getInt()` and `getLong()`, I think its reasonable to >> use other means for these methods in the interest of consistency due to, as >> you pointed out, only `int` being supported. Would you think? Or would it be >> better to use the same means in all 3 methods? > > Its a slippery slope that might require a bit more investigation to check the > expected value sizes to see if a change to the number of bits in the value > for each property might break something. Technical debt can take you down a > rabbit hole. Quickest to just convert to the lamba as you proposed. I have stuck with the lambda conversion solution in the [current changes](https://github.com/openjdk/jdk/pull/3416/commits/1746840eaa9a8de34d89d73d993e2f86aa0d0ed3), however WRT to Alan's previous feedback on creating a PrivilegedAction explicitly as it makes everything a bit more readable. - PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2]
> ### Description > This fix is part of a previous effort to both cleanup/modernise JNDI code, > the details of which can be seen in > [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number > JNDI methods under `java.naming` use Anonymous Inner Classes in cases where > only a single object unique to the requirements of the method is used. The > issues these occurrences of AICs cause are highlighted below. > > - AICs, in the cases concerned with this fix, are used where only one > operation is required. While AICs can be useful for more complex > implementations (using interfaces, multiple methods needed, local fields > etc.), Lambdas are better suited here as they result in a more readable and > concise solution. > > ### Fixes > - Where applicable, occurrences of AICs were replaced with lambdas to address > the issues above resulting primarily in more readable/concise code. Conor Cleary has updated the pull request incrementally with two additional commits since the last revision: - Update copyright headers - Tidied up lambdas - Changes: - all: https://git.openjdk.java.net/jdk/pull/3416/files - new: https://git.openjdk.java.net/jdk/pull/3416/files/f0c2238a..840ea35c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3416=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3416=00-01 Stats: 29 lines in 5 files changed: 1 ins; 7 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416 PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI
On Fri, 9 Apr 2021 13:46:46 GMT, Roger Riggs wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, >> the details of which can be seen in >> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number >> JNDI methods under `java.naming` use Anonymous Inner Classes in cases where >> only a single object unique to the requirements of the method is used. The >> issues these occurrences of AICs cause are highlighted below. >> >> - AICs, in the cases concerned with this fix, are used where only one >> operation is required. While AICs can be useful for more complex >> implementations (using interfaces, multiple methods needed, local fields >> etc.), Lambdas are better suited here as they result in a more readable and >> concise solution. >> >> ### Fixes >> - Where applicable, occurrences of AICs were replaced with lambdas to >> address the issues above resulting primarily in more readable/concise code. > > src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line 413: > >> 411: return AccessController.doPrivileged( >> 412: (PrivilegedAction) () -> Long.getLong(propName, >> defVal).longValue() >> 413: ); > > And GetIntegerAction here. Though it only supports an int value. Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop, default)` for the `getProperty()` method looks great. WRT to using it for `getInt()` and `getLong()`, I think its reasonable to use other means for these methods in the interest of consistency due to, as you pointed out, only `int` being supported. Would you think? Or would it be better to use the same means in all 3 methods? - PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI
On Fri, 9 Apr 2021 14:01:32 GMT, Roger Riggs wrote: >> That is a very neat alternative yes. Approaching the problem like that >> especially improves the readability >> [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) >> in my opinion. >> I don't think casting has any major performance hits for these fixes, so is >> your suggestion mostly for readability's sake? > > Right, not a performance problem. Just simpler to use an existing method to > read a privileged property. > And there will be one less doPriv. I think I may change the PR to reflect what Alan suggested. Its more readable than the lambda-with-cast solution in that an action is created _and then_ an action is carried out as supposed to fitting it all into one call. Its also as concise. - PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI
On Fri, 9 Apr 2021 13:45:03 GMT, Roger Riggs wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/LdapPoolManager.java line >> 401: >> >>> 399: return AccessController.doPrivileged( >>> 400: (PrivilegedAction) () -> >>> System.getProperty(propName, defVal) >>> 401: ); >> >> If you want to avoid the cast then you could create the PrivilegedAction >> explicitly, e.g. >> >> PrivilegedAction pa = () -> System.getProperty(propName, defVal); >> return AccessController.doPrivileged(pa); > > An alternative here would be to use > sun.security.action.privilegedGetProperty(prop, default). > The package is already exported from java.base to java.desktop, etc. That is a very neat alternative yes. Approaching the problem like that especially improves the readability [JdkLDAP.java](https://github.com/openjdk/jdk/pull/3416/files#diff-bf4c67da93cf2b9196508db2d57f7e01bc884f2268f5bfd43a9f01dfd55e4955) in my opinion. I don't think casting has any major performance hits for these fixes, so is your suggestion mostly for readability's sake? - PR: https://git.openjdk.java.net/jdk/pull/3416
RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI
### Description This fix is part of a previous effort to both cleanup/modernise JNDI code, the details of which can be seen in [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number JNDI methods under `java.naming` use Anonymous Inner Classes in cases where only a single object unique to the requirements of the method is used. The issues these occurrences of AICs cause are highlighted below. - AICs, in the cases concerned with this fix, are used where only one operation is required. While AICs can be useful for more complex implementations (using interfaces, multiple methods needed, local fields etc.), Lambdas are better suited here as they result in a more readable and concise solution. ### Fixes - Where applicable, occurrences of AICs were replaced with lambdas to address the issues above resulting primarily in more readable/concise code. - Commit messages: - 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI Changes: https://git.openjdk.java.net/jdk/pull/3416/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3416=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8048199 Stats: 75 lines in 5 files changed: 0 ins; 42 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/3416.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3416/head:pull/3416 PR: https://git.openjdk.java.net/jdk/pull/3416
Re: RFR: 8263552: Use String.valueOf() for char-to-String conversion in ObjectStreamClass
On Sat, 20 Feb 2021 12:17:32 GMT, Сергей Цыпанов wrote: > This is a very simple and trivial improvement about getting rid of pointless > char wrapping into array src/java.base/share/classes/java/io/ObjectStreamClass.java line 833: > 831: String fname = in.readUTF(); > 832: String signature = ((tcode == 'L') || (tcode == '[')) ? > 833: in.readTypeString() : String.valueOf(tcode); Certainly more readable and it seems that the call to valueOf is equivalent to whay takes place with the original code. I can't see any difference semantically or performance-wise at a glance. LGTM - PR: https://git.openjdk.java.net/jdk/pull/2660
Integrated: 8256154: Some TestNG tests require default constructors
On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary wrote:
> In TestNG 7, it is a requirement that TestNG is able to create a Test object
> using a default constructor.
>
> This simple fix addresses two such classes so that this requirement is
> satisfied by inserting default construtors. Example: `public GetPackages() {
> ... }`
>
> test/jdk/java/lang/Package/GetPackages.java
> test/jdk/java/lang/StackWalker/Basic.java
This pull request has now been integrated.
Changeset: 5ed70448
Author:Conor Cleary
Committer: Lance Andersen
URL: https://git.openjdk.java.net/jdk/commit/5ed70448
Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod
8256154: Some TestNG tests require default constructors
Reviewed-by: dfuchs, bpb
-
PR: https://git.openjdk.java.net/jdk/pull/1317
Integrated: 8256183: InputStream.skipNBytes is missing @since 12
On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary wrote: > InputStream.skipNBytes is missing `@since 12` tag which was not added during > the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099). > > This small fix adds the `@since` tag to InputStream.skipNBytes This pull request has now been integrated. Changeset: be6c8936 Author:Conor Cleary Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/be6c8936 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8256183: InputStream.skipNBytes is missing @since 12 Reviewed-by: dfuchs, lancea, bpb - PR: https://git.openjdk.java.net/jdk/pull/1314
Re: RFR: 8256154: Some TestNG tests require default constructors
On Thu, 19 Nov 2020 16:44:52 GMT, Lance Andersen wrote: >> `depth` is `final`, so it needs to be assigned. but this could be replaced >> with `this(0)` > > Ah, missed the final on depth :-) Any particular strengths associated with `this(0)` as opposed to the actual assignment? Aside from the brevity it provides of course. Happy to modify the PR to include it - PR: https://git.openjdk.java.net/jdk/pull/1317
Re: RFR: 8256154: Some TestNG tests require default constructors
On Thu, 19 Nov 2020 15:09:30 GMT, Daniel Fuchs wrote: > Hi Conor, > > Were you able to verify that the two tests passed properly (and non > trivially) with both the current version of TestNG as well as the new version? > > best regards, > > -- daniel Hi Daniel, Yes, I was able to verify that the tests do indeed fail with TestNG 7.1 7.1 is the version that is currently specified with the latest Jtreg build, see L54 in https://github.com/openjdk/jtreg/blob/master/make/build-support/version-numbers Tests failed across Mac, Linux and Windows platforms with `org.testng.TestNGException: An error occurred while instantiating class SomeTestClass. Check to make sure it can be instantiated ` However when modified as in this PR, they pass. - PR: https://git.openjdk.java.net/jdk/pull/1317
RFR: 8256154: Some TestNG tests require default constructors
In TestNG 7, it is a requirement that TestNG is able to create a Test object
using a default constructor.
This simple fix addresses two such classes so that this requirement is
satisfied by inserting default construtors. Example: `public GetPackages() {
... }`
test/jdk/java/lang/Package/GetPackages.java
test/jdk/java/lang/StackWalker/Basic.java
-
Commit messages:
- 8256154: Some TestNG tests require default constructors
Changes: https://git.openjdk.java.net/jdk/pull/1317/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1317=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8256154
Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod
Patch: https://git.openjdk.java.net/jdk/pull/1317.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/1317/head:pull/1317
PR: https://git.openjdk.java.net/jdk/pull/1317
RFR: 8256183: InputStream.skipNBytes is missing @since 12
InputStream.skipNBytes is missing `@since 12` tag which was not added during the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099). This small fix adds the `@since` tag to InputStream.skipNBytes - Commit messages: - 8256183: InputStream.skipNBytes is missing @since 12 Changes: https://git.openjdk.java.net/jdk/pull/1314/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1314=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256183 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1314.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1314/head:pull/1314 PR: https://git.openjdk.java.net/jdk/pull/1314
Re: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs [v2]
On Wed, 16 Sep 2020 08:52:35 GMT, Chris Hegarty wrote: > The CSR lists `com.sun.java.accessibility.util.SwingEventMonitor` as being > changed, but I cannot find that class in > this PR. Changes to this class were indeed missing. This has now been addressed. Thanks for spotting that! - PR: https://git.openjdk.java.net/jdk/pull/174
Re: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs [v2]
> This issue relates to JDK-8250639 '☂ Address reliance on default constructors > in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a > protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a > public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html > bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 Conor Cleary has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8250859: Added no-arg constructor to SwingEventMonitor.java - Merge remote-tracking branch 'origin/master' into JDK-8250859 - Merge remote-tracking branch 'origin/master' into JDK-8250859 - 8250859: Address reliance on default constructors in the Accessibility APIs - Changes: - all: https://git.openjdk.java.net/jdk/pull/174/files - new: https://git.openjdk.java.net/jdk/pull/174/files/a2946aca..bc02a4de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=174=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=174=00-01 Stats: 2012 lines in 47 files changed: 486 ins; 1201 del; 325 mod Patch: https://git.openjdk.java.net/jdk/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk/pull/174
RFR: 8250859: Address reliance on default constructors in the Accessibility APIs
This issue relates to JDK-8250639 '☂ Address reliance on default constructors in the java.desktop module'. The following classes have had an explicit no-arg constructor added, with a protected access modifier and accompanying API description: - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor - Default ctor on javax.accessibility.AccessibleContext - Default ctor on javax.accessibility.AccessibleHyperlink The following classes have had an explicit no-arg constructor added, with a public access modifier and accompanying API description: - Default ctor on javax.accessibility.AccessibleResourceBundle - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList - Default ctor on com.sun.java.accessibility.util.EventID specdiff: http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html bug: https://bugs.openjdk.java.net/browse/JDK-8250859 - Commit messages: - 8250859: Address reliance on default constructors in the Accessibility APIs Changes: https://git.openjdk.java.net/jdk/pull/174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=174=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250859 Stats: 42 lines in 7 files changed: 35 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/174/head:pull/174 PR: https://git.openjdk.java.net/jdk/pull/174
Re: RFR: 8250859: Address reliance on default constructors in the Accessibility APIs
On Tue, 15 Sep 2020 10:04:49 GMT, Conor Cleary wrote: > This issue relates to JDK-8250639 '☂ Address reliance on default constructors > in the java.desktop module'. The > following classes have had an explicit no-arg constructor added, with a > protected access modifier and accompanying API > description: > - Default ctor on com.sun.java.accessibility.util.SwingEventMonitor > - Default ctor on javax.accessibility.AccessibleContext > - Default ctor on javax.accessibility.AccessibleHyperlink > > The following classes have had an explicit no-arg constructor added, with a > public access modifier and accompanying API > description: > - Default ctor on javax.accessibility.AccessibleResourceBundle > - Default ctor on com.sun.java.accessibility.util.AWTEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityEventMonitor > - Default ctor on com.sun.java.accessibility.util.AccessibilityListenerList > - Default ctor on com.sun.java.accessibility.util.EventID > > specdiff: > http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250859/webrevs/webrev.00/specdiff/overview-summary.html > bug: > https://bugs.openjdk.java.net/browse/JDK-8250859 Changes require approval of CSR, can't request that requirement myself as I am not a reviewer - PR: https://git.openjdk.java.net/jdk/pull/174
RFR[8243655]: 'Map.replace javadoc code snippet typo'
Hi, Could someone please take a look at my webrev for JDK-8243655 'Map.replace javadoc code snippet typo'? This fix addresses a typo in the javadoc for Map.replace(K, V, V) in the default implementation code. The parameter 'value' in the conditional block is changed to 'oldValue' to reflect the originally passed variable name. bug: https://bugs.openjdk.java.net/browse/JDK-8243655 webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8243655/webrev.00/ Regards, Conor
RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'
Hi, Could someone please review my webrev for JDK-8245658 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'? In Arrays.java Javadoc, there were two instances of bad Unicode formatting where the null character constant was incorrectly specified with '\u000' (another zero is required). This fix displays the correct Unicode constants in the Javadoc so that outputted docs display '\u'. bug: https://bugs.openjdk.java.net/browse/JDK-8245658 webrev: http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ Regards, Conor
RFR(xs): 8245970: IntStream.html#reduce doc should not mention average
Hi, The method-level documentation of Intstream::reduce(int, IntBinaryOperator) mentions the average function as a case of reduction even though the function cannot be used with the reduce method. This might cause confusion, this fix therefore removes the mention of the average function from the @apiNote. bug: https://bugs.openjdk.java.net/browse/JDK-8245970 webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ Regards, Conor
