Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

[Mandy Chung]

On Tue, 24 Aug 2021 03:03:37 GMT, Vicente Romero  wrote:

>> src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327:
>> 
>>> 325:  * @throws IllegalArgumentException if the bootstrap arguments are 
>>> invalid
>>> 326:  *  or inconsistent
>>> 327:  * @throws NullPointerException if any argument but {@code lookup} 
>>> is {@code null}
>> 
>> `names` may be null if the {@code methodName} is {@code "equals"} or {@code 
>> "hashCode"}.This should be captured here.
>
> Hi Mandy, I have changed the implementation of the method to explicitly 
> require all arguments but lookup to be non-null as suggested by Brian. I have 
> also covered, I think, all the missing test cases in test 
> `ObjectMethodsTest`, thanks for your comments.

I think you meant requiring `names` to be non-null but `lookup` may still be 
null.  It's okay to change the spec to require `names` to be non-null.  

Probably better to mention in `@param names` that `names` is ignored when the 
`methodName` is `equals` or `hashCode`.

-

PR: https://git.openjdk.java.net/jdk/pull/5226

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java

[Ioi Lam]

On Tue, 24 Aug 2021 19:15:56 GMT, Roger Riggs  wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2635:
>> 
>>> 2633: List childArgs = null;
>>> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis");
>>> 2635: if (sleepExe.toFile().canExecute()) {
>> 
>> Why is the fallback necessary? Other test cases such as 
>> test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback.
>> 
>> Also, I noticed that JliLaunchTest does something like this:
>> 
>> 
>> Path launcher = Paths.get(System.getProperty("test.nativepath"),
>> "JliLaunchTest" + (Platform.isWindows() ? ".exe" : ""));
>> 
>> 
>> but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java 
>> doesn't add ".exe", so it may not be necessary.
>
> See above, the java Child is more portable and lower maintenance.
> Windows looks for xxx.exe if xxx is not found.

How about adding a comment to explain why the fallback is necessary?

Also, if `jtreg -nativepath:xxx` is specified, but there's no xxx/sleepmillis, 
or xxx/sleepmillis is not executable, that should be a setup error (or a bug in 
the test itself). E.g., if we are testing inside mach5, we should always 
execute the native program, and should not silently fallback to the java Child 
program. Otherwise, setup problems in mach5 might bring us back to the 
mysterious intermittent failure.

(The current version of the code is buggy on Windows and will always silently 
fall back to Child because the executable is named "sleepmillis.exe", not 
"sleepmillis").

-

PR: https://git.openjdk.java.net/jdk/pull/5239

Re: RFR: 8272473: Parsing epoch seconds at a DST transition with a non-UTC parser is wrong

[Joe Wang]

On Mon, 23 Aug 2021 16:42:03 GMT, Naoto Sato  wrote:

> Please review the fix to the subject issue. When instant seconds and zone 
> co-exist in parsed data, instant seconds was not resolved correctly from them.

Marked as reviewed by joehw (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5225

Integrated: JDK-8272639: jpackaged applications using microphone on mac

[Andy Herrick]

On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick  wrote:

> JDK-8272639: jpackaged applications using microphone on mac

This pull request has now been integrated.

Changeset: b17b821a
Author:Andy Herrick 
URL:   
https://git.openjdk.java.net/jdk/commit/b17b821a570930e4188bcdfb396f0a7abe99caf6
Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod

8272639: jpackaged applications using microphone on mac

Reviewed-by: almatvee, serb

-

PR: https://git.openjdk.java.net/jdk/pull/5186

Re: RFR: 8272861: Add a micro benchmark for vector api [v3]

[Sandhya Viswanathan]

On Tue, 24 Aug 2021 10:09:13 GMT, Aleksey Shipilev  wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Make constants as static final
>
> Some benchmark comments.

@shipilev @nsjian Thanks a lot for the feedback. I have implemented your review 
comments.

-

PR: https://git.openjdk.java.net/jdk/pull/5234

Re: RFR: 8272861: Add a micro benchmark for vector api [v3]

[Sandhya Viswanathan]

> This pull request adds a micro benchmark for Vector API.
> The Black Scholes algorithm is implemented with and without Vector API.
> We see about ~6x gain with Vector API for this micro benchmark using 256 bit 
> vectors.

Sandhya Viswanathan has updated the pull request incrementally with one 
additional commit since the last revision:

  Make constants as static final

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5234/files
  - new: https://git.openjdk.java.net/jdk/pull/5234/files/f92994cd..5b4abbf9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5234=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5234=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5234/head:pull/5234

PR: https://git.openjdk.java.net/jdk/pull/5234

Re: RFR: 8272861: Add a micro benchmark for vector api [v2]

[Sandhya Viswanathan]

> This pull request adds a micro benchmark for Vector API.
> The Black Scholes algorithm is implemented with and without Vector API.
> We see about ~6x gain with Vector API for this micro benchmark using 256 bit 
> vectors.

Sandhya Viswanathan has updated the pull request incrementally with one 
additional commit since the last revision:

  Implement review comments

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5234/files
  - new: https://git.openjdk.java.net/jdk/pull/5234/files/ca688faa..f92994cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5234=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5234=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5234/head:pull/5234

PR: https://git.openjdk.java.net/jdk/pull/5234

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules [v2]

[Andrey Turbanov]

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

Andrey Turbanov has updated the pull request incrementally with one additional 
commit since the last revision:

  8272863: Replace usages of Collections.sort with List.sort call in public 
java modules
  replace Collections.sort without comparator too

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5229/files
  - new: https://git.openjdk.java.net/jdk/pull/5229/files/e31936a5..d6dfc8bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5229=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5229=00-01

  Stats: 21 lines in 10 files changed: 0 ins; 4 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229

PR: https://git.openjdk.java.net/jdk/pull/5229

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Andrey Turbanov]

On Tue, 24 Aug 2021 11:48:46 GMT, Alexander Zvegintsev  
wrote:

> Is there any reason to not touch them along with this fix?

Update them too.

-

PR: https://git.openjdk.java.net/jdk/pull/5229

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java

[Roger Riggs]

On Tue, 24 Aug 2021 16:16:45 GMT, Ioi Lam  wrote:

>> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified 
>> unexpected messages from a child Java VM
>> as the cause of the test failure.  Attempts to control the output of the 
>> child VM have failed, the VM is unrepentant .
>> 
>> There is no functionality in the child except to wait long enough for the 
>> test to finish and the child is destroyed.
>> The fix is to switch from using a Java child to using a native child; a new 
>> executable `sleepmillis`.
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 2635:
> 
>> 2633: List childArgs = null;
>> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis");
>> 2635: if (sleepExe.toFile().canExecute()) {
> 
> Why is the fallback necessary? Other test cases such as 
> test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback.
> 
> Also, I noticed that JliLaunchTest does something like this:
> 
> 
> Path launcher = Paths.get(System.getProperty("test.nativepath"),
> "JliLaunchTest" + (Platform.isWindows() ? ".exe" : ""));
> 
> 
> but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java 
> doesn't add ".exe", so it may not be necessary.

See above, the java Child is more portable and lower maintenance.
Windows looks for xxx.exe if xxx is not found.

> test/jdk/java/lang/ProcessBuilder/exeSleepMillis.c line 45:
> 
>> 43: sleeptime.tv_nsec = (millis % 1000) * 1000 * 1000;
>> 44: int rc;
>> 45: while ((rc = nanosleep(, )) > 0) {
> 
> is `nanosleep` a portable call? I couldn't find documentation for it with 
> google search of `nanosleep site:docs.microsoft.com`.

Sadly, true.
Falling back to the portable 'sleep(seconds)' is necessary; but the timing will 
be less precise.
C++ supports a higher resolution 'sleep_for' but the JDK native test build does 
not support building
main programs using C++ and its not worth the complications added.

-

PR: https://git.openjdk.java.net/jdk/pull/5239

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java

[Roger Riggs]

On Tue, 24 Aug 2021 16:14:16 GMT, Ioi Lam  wrote:

>> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified 
>> unexpected messages from a child Java VM
>> as the cause of the test failure.  Attempts to control the output of the 
>> child VM have failed, the VM is unrepentant .
>> 
>> There is no functionality in the child except to wait long enough for the 
>> test to finish and the child is destroyed.
>> The fix is to switch from using a Java child to using a native child; a new 
>> executable `sleepmillis`.
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 30:
> 
>> 28:  *  6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958
>> 29:  *  4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464
>> 30:  *  8067796 8224905 8263729 8265173 8272600 8231297
> 
> The test should also be modified to use `@run 
> main/othervm/native/timeout=300` so that this test will be flagged by jtreg 
> if `-nativepath:` is not specified.

It should be possible to run this test as a main, without the overhead of 
building the native image.
The use of a Java child greatly reduces the complexity of the test and improves 
its maintainability.
Requiring a native special built program raises the overhead considerably.
And all because the VM can't or won't allow its output to be managed.

-

PR: https://git.openjdk.java.net/jdk/pull/5239

Integrated: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java

[Calvin Cheung]

On Tue, 24 Aug 2021 17:21:20 GMT, Calvin Cheung  wrote:

> Please review this trivial change for fixing the copyright year of the two 
> files (jlink.properties and ImagePluginStack.java) which were modified 
> unintentionally during the fix for JDK-8264322.

This pull request has now been integrated.

Changeset: c547ead4
Author:Calvin Cheung 
URL:   
https://git.openjdk.java.net/jdk/commit/c547ead493fafb6716550996a83276afc0ec018a
Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8272916: Copyright year was modified unintentionally in jlink.properties and 
ImagePluginStack.java

Reviewed-by: bpb

-

PR: https://git.openjdk.java.net/jdk/pull/5240

Re: RFR: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java

[Calvin Cheung]

On Tue, 24 Aug 2021 17:35:50 GMT, Brian Burkhalter  wrote:

>> Please review this trivial change for fixing the copyright year of the two 
>> files (jlink.properties and ImagePluginStack.java) which were modified 
>> unintentionally during the fix for JDK-8264322.
>
> I verified that in the commit to fix JDK-8264322 no content changes were 
> actually made to the files in this commit. Approved.

@bplb Thanks for your quick review.

-

PR: https://git.openjdk.java.net/jdk/pull/5240

Re: RFR: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java

[Brian Burkhalter]

On Tue, 24 Aug 2021 17:21:20 GMT, Calvin Cheung  wrote:

> Please review this trivial change for fixing the copyright year of the two 
> files (jlink.properties and ImagePluginStack.java) which were modified 
> unintentionally during the fix for JDK-8264322.

I verified that in the commit to fix JDK-8264322 no content changes were 
actually made to the files in this commit. Approved.

-

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5240

RFR: 8272916: Copyright year was modified unintentionally in jlink.properties and ImagePluginStack.java

[Calvin Cheung]

Please review this trivial change for fixing the copyright year of the two 
files (jlink.properties and ImagePluginStack.java) which were modified 
unintentionally during the fix for JDK-8264322.

-

Commit messages:
 - 8272916: Copyright year was modified unintentionally in jlink.properties and 
ImagePluginStack.java

Changes: https://git.openjdk.java.net/jdk/pull/5240/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5240=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272916
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5240.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5240/head:pull/5240

PR: https://git.openjdk.java.net/jdk/pull/5240

Re: Dangling class-level javadoc comments in JDK

[Jonathan Gibbons]

The poor-man's solution would be to detect common cases, with the 
comment appearing before a package or import statement.


A more advanced solution would have to be in the lexer or parser, 
detecting that there is a "unused" comment when creating a tree node.


-- Jon

On 8/24/21 8:07 AM, Pavel Rappo wrote:

On 24 Aug 2021, at 15:38, Jonathan Gibbons  wrote:

IIRC, the one in javadoc CommentUtils has recently been fixed.

It might be worth a javac -Xlint option to detect/report such dangling comments.

How would you currently implement that? Aren't comments on non-documentable 
constructs discarded early? At what point during compilation and how would you 
detect, for example, that this doc comment dangles?

 /**
  * IOUtils: A collection of IO-related public static methods.
  */
 
 package sun.security.util;


-Pavel


-- Jon

On 8/23/21 11:50 PM, Andrey Turbanov wrote:

Hello.
I found a few internal classes in the JDK codebase which don't have
proper javadoc, but have dangling javadoc-like comments.
Dangling Javadoc comments are ignored by the javadoc tool and IDE.
Perhaps it was intentional to not add proper javadoc to them?
I believe it's better to convert them to proper javadoc to make
developing JDK a bit more friendly within IDE.
What do you think?

List of classes:

com.sun.beans.editors.BooleanEditor
com.sun.beans.editors.ByteEditor
com.sun.beans.editors.DoubleEditor
com.sun.beans.editors.FloatEditor
com.sun.beans.editors.IntegerEditor
com.sun.beans.editors.LongEditor
com.sun.beans.editors.NumberEditor
com.sun.beans.editors.ShortEditor
com.sun.jndi.toolkit.dir.ContainmentFilter
com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl
com.sun.security.auth.module.Crypt
java.math.MutableBigInteger
java.net.DefaultInterface
javax.swing.GraphicsWrapper
jdk.internal.access.JavaAWTFontAccess
jdk.javadoc.internal.doclets.toolkit.CommentUtils
sun.awt.X11.XAtom
sun.awt.X11.XAwtState
sun.java2d.xr.XRBackend
sun.java2d.xr.XRDrawLine
sun.jvm.hotspot.debugger.PageCache
sun.jvm.hotspot.runtime.JavaThreadFactory
sun.jvm.hotspot.utilities.Interval
sun.jvm.hotspot.utilities.MessageQueueBackend
sun.jvm.hotspot.utilities.RBTree
sun.launcher.LauncherHelper
sun.net.www.content.text.plain
sun.net.www.protocol.file.FileURLConnection
sun.nio.ch.Interruptible
sun.security.pkcs.ParsingException
sun.security.provider.SeedGenerator
sun.security.util.ByteArrayTagOrder
sun.security.util.IOUtils


Andrey Turbanov

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java

[Ioi Lam]

On Tue, 24 Aug 2021 15:55:28 GMT, Roger Riggs  wrote:

> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified 
> unexpected messages from a child Java VM
> as the cause of the test failure.  Attempts to control the output of the 
> child VM have failed, the VM is unrepentant .
> 
> There is no functionality in the child except to wait long enough for the 
> test to finish and the child is destroyed.
> The fix is to switch from using a Java child to using a native child; a new 
> executable `sleepmillis`.

test/jdk/java/lang/ProcessBuilder/Basic.java line 30:

> 28:  *  6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958
> 29:  *  4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464
> 30:  *  8067796 8224905 8263729 8265173 8272600 8231297

The test should also be modified to use `@run main/othervm/native/timeout=300` 
so that this test will be flagged by jtreg if `-nativepath:` is not specified.

test/jdk/java/lang/ProcessBuilder/Basic.java line 2635:

> 2633: List childArgs = null;
> 2634: Path sleepExe = TEST_NATIVEPATH.resolve("sleepmillis");
> 2635: if (sleepExe.toFile().canExecute()) {

Why is the fallback necessary? Other test cases such as 
test/jdk/tools/launcher/JliLaunchTest.java do not have such a fallback.

Also, I noticed that JliLaunchTest does something like this:


Path launcher = Paths.get(System.getProperty("test.nativepath"),
"JliLaunchTest" + (Platform.isWindows() ? ".exe" : ""));


but test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java 
doesn't add ".exe", so it may not be necessary.

test/jdk/java/lang/ProcessBuilder/exeSleepMillis.c line 45:

> 43: sleeptime.tv_nsec = (millis % 1000) * 1000 * 1000;
> 44: int rc;
> 45: while ((rc = nanosleep(, )) > 0) {

is `nanosleep` a portable call? I couldn't find documentation for it with 
google search of `nanosleep site:docs.microsoft.com`.

-

PR: https://git.openjdk.java.net/jdk/pull/5239

RFR: 8272600: (test) Use native "sleep" in Basic.java

[Roger Riggs]

The intermittent test in java/lang/ProcessBuilder/Basic.java has identified 
unexpected messages from a child Java VM
as the cause of the test failure.  Attempts to control the output of the child 
VM have failed, the VM is unrepentant .

There is no functionality in the child except to wait long enough for the test 
to finish and the child is destroyed.
The fix is to switch from using a Java child to using a native child; a new 
executable `sleepmillis`.

-

Commit messages:
 - 8272600: (test) Use native "sleep" in Basic.java

Changes: https://git.openjdk.java.net/jdk/pull/5239/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5239=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272600
  Stats: 116 lines in 2 files changed: 70 ins; 34 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5239.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5239/head:pull/5239

PR: https://git.openjdk.java.net/jdk/pull/5239

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Naoto Sato]

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov 
 wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

java.time changes look good.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5229

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2]

[Calvin Cheung]

On Tue, 24 Aug 2021 02:16:31 GMT, Mandy Chung  wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   @mlchung comments
>
> Thanks for creating a JBS issue.  I'm okay to follow up the test improvement 
> as a separate issue.

@mlchung, @AlanBateman Thanks for the review and discussions.

-

PR: https://git.openjdk.java.net/jdk/pull/5174

Integrated: 8264322: Generate CDS archive when creating custom JDK image

[Calvin Cheung]

On Wed, 18 Aug 2021 21:21:06 GMT, Calvin Cheung  wrote:

> Please review this change for adding a `jlink` command line option 
> `--generate-cds-archive` for generating CDS archives as a post processing 
> step during the creation of a custom JDK image.
> 
> Details can be found in the corresponding CSR 
> [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178).
> 
> Testing:
> 
> - [x] tiers 1,2 (including the new test)

This pull request has now been integrated.

Changeset: f608e81a
Author:Calvin Cheung 
URL:   
https://git.openjdk.java.net/jdk/commit/f608e81ad8309a001b8a92563a93b8adee1ce2b8
Stats: 372 lines in 11 files changed: 329 ins; 7 del; 36 mod

8264322: Generate CDS archive when creating custom JDK image

Reviewed-by: mchung, alanb

-

PR: https://git.openjdk.java.net/jdk/pull/5174

Re: Dangling class-level javadoc comments in JDK

[Pavel Rappo]

Just to clarify that example of mine. I didn't mean the package-info.java file. 
I meant an ordinary file that comprises an interface, class, enum or record. 
Perhaps a better example from Andrey's list would be this:

/**
 * A utility package for the java(1), javaw(1) launchers.
 * The following are helper methods that the native launcher uses
 * to perform checks etc. using JNI, see src/share/bin/java.c
 */
import java.io.File;

In no context can an import statement be documented.

-Pavel

> On 24 Aug 2021, at 16:07, Pavel Rappo  wrote:
> 
>> On 24 Aug 2021, at 15:38, Jonathan Gibbons  
>> wrote:
>> 
>> IIRC, the one in javadoc CommentUtils has recently been fixed.
>> 
>> It might be worth a javac -Xlint option to detect/report such dangling 
>> comments.
> 
> How would you currently implement that? Aren't comments on non-documentable 
> constructs discarded early? At what point during compilation and how would 
> you detect, for example, that this doc comment dangles?
> 
>/**
> * IOUtils: A collection of IO-related public static methods.
> */
> 
>package sun.security.util;
> 
> -Pavel
> 
>> -- Jon
>> 
>> On 8/23/21 11:50 PM, Andrey Turbanov wrote:
>>> Hello.
>>> I found a few internal classes in the JDK codebase which don't have
>>> proper javadoc, but have dangling javadoc-like comments.
>>> Dangling Javadoc comments are ignored by the javadoc tool and IDE.
>>> Perhaps it was intentional to not add proper javadoc to them?
>>> I believe it's better to convert them to proper javadoc to make
>>> developing JDK a bit more friendly within IDE.
>>> What do you think?
>>> 
>>> List of classes:
>>> 
>>> com.sun.beans.editors.BooleanEditor
>>> com.sun.beans.editors.ByteEditor
>>> com.sun.beans.editors.DoubleEditor
>>> com.sun.beans.editors.FloatEditor
>>> com.sun.beans.editors.IntegerEditor
>>> com.sun.beans.editors.LongEditor
>>> com.sun.beans.editors.NumberEditor
>>> com.sun.beans.editors.ShortEditor
>>> com.sun.jndi.toolkit.dir.ContainmentFilter
>>> com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl
>>> com.sun.security.auth.module.Crypt
>>> java.math.MutableBigInteger
>>> java.net.DefaultInterface
>>> javax.swing.GraphicsWrapper
>>> jdk.internal.access.JavaAWTFontAccess
>>> jdk.javadoc.internal.doclets.toolkit.CommentUtils
>>> sun.awt.X11.XAtom
>>> sun.awt.X11.XAwtState
>>> sun.java2d.xr.XRBackend
>>> sun.java2d.xr.XRDrawLine
>>> sun.jvm.hotspot.debugger.PageCache
>>> sun.jvm.hotspot.runtime.JavaThreadFactory
>>> sun.jvm.hotspot.utilities.Interval
>>> sun.jvm.hotspot.utilities.MessageQueueBackend
>>> sun.jvm.hotspot.utilities.RBTree
>>> sun.launcher.LauncherHelper
>>> sun.net.www.content.text.plain
>>> sun.net.www.protocol.file.FileURLConnection
>>> sun.nio.ch.Interruptible
>>> sun.security.pkcs.ParsingException
>>> sun.security.provider.SeedGenerator
>>> sun.security.util.ByteArrayTagOrder
>>> sun.security.util.IOUtils
>>> 
>>> 
>>> Andrey Turbanov
> 

Re: Dangling class-level javadoc comments in JDK

[Pavel Rappo]

> On 24 Aug 2021, at 15:38, Jonathan Gibbons  
> wrote:
> 
> IIRC, the one in javadoc CommentUtils has recently been fixed.
> 
> It might be worth a javac -Xlint option to detect/report such dangling 
> comments.

How would you currently implement that? Aren't comments on non-documentable 
constructs discarded early? At what point during compilation and how would you 
detect, for example, that this doc comment dangles?

/**
 * IOUtils: A collection of IO-related public static methods.
 */

package sun.security.util;

-Pavel

> -- Jon
> 
> On 8/23/21 11:50 PM, Andrey Turbanov wrote:
>> Hello.
>> I found a few internal classes in the JDK codebase which don't have
>> proper javadoc, but have dangling javadoc-like comments.
>> Dangling Javadoc comments are ignored by the javadoc tool and IDE.
>> Perhaps it was intentional to not add proper javadoc to them?
>> I believe it's better to convert them to proper javadoc to make
>> developing JDK a bit more friendly within IDE.
>> What do you think?
>> 
>> List of classes:
>> 
>> com.sun.beans.editors.BooleanEditor
>> com.sun.beans.editors.ByteEditor
>> com.sun.beans.editors.DoubleEditor
>> com.sun.beans.editors.FloatEditor
>> com.sun.beans.editors.IntegerEditor
>> com.sun.beans.editors.LongEditor
>> com.sun.beans.editors.NumberEditor
>> com.sun.beans.editors.ShortEditor
>> com.sun.jndi.toolkit.dir.ContainmentFilter
>> com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl
>> com.sun.security.auth.module.Crypt
>> java.math.MutableBigInteger
>> java.net.DefaultInterface
>> javax.swing.GraphicsWrapper
>> jdk.internal.access.JavaAWTFontAccess
>> jdk.javadoc.internal.doclets.toolkit.CommentUtils
>> sun.awt.X11.XAtom
>> sun.awt.X11.XAwtState
>> sun.java2d.xr.XRBackend
>> sun.java2d.xr.XRDrawLine
>> sun.jvm.hotspot.debugger.PageCache
>> sun.jvm.hotspot.runtime.JavaThreadFactory
>> sun.jvm.hotspot.utilities.Interval
>> sun.jvm.hotspot.utilities.MessageQueueBackend
>> sun.jvm.hotspot.utilities.RBTree
>> sun.launcher.LauncherHelper
>> sun.net.www.content.text.plain
>> sun.net.www.protocol.file.FileURLConnection
>> sun.nio.ch.Interruptible
>> sun.security.pkcs.ParsingException
>> sun.security.provider.SeedGenerator
>> sun.security.util.ByteArrayTagOrder
>> sun.security.util.IOUtils
>> 
>> 
>> Andrey Turbanov

Re: Proposal: JDK-8231640 - (prop) Canonical property storage

[Roger Riggs]

Hi Jaikiran,

Thanks for taking this on and getting it started.

One use case of canonical storage is repeatable builds.
It would be useful to identify the uses in the JDK that would need to be 
changed to use the new function.


On 8/24/21 10:07 AM, Jaikiran Pai wrote:
The java.util.Properties class allows the properties to be written out 
to a stream or through a writer. In its current form, the 
specification of these APIs state that a comment comprising of the 
current date is always written out. The spec doesn't make any 
guarantees about the order of the properties when they are written out.


There have been requests asking to make these APIs more deterministic. 
These requests, from what I have seen, mainly ask for:


- A way to disable writing out the date comment
- A way to write out the properties in a deterministic and 
reproducible way


There have been discussions in the mailing list in the past which have 
been captured in JDK-8231640[1]. In these discussions, there has been 
an inclination to not touch the current existing API implementations 
and instead introduce new API(s) to achieve the proposed use cases.


Before starting off with an implementation, I wanted to try and get 
some inputs on what the new API(s) would look like and what the scope 
of such a work should be.


Right now, the Properties class has 2 "store" APIs:

    public void store(Writer writer, String comments) throws IOException
    public void store(OutputStream out, String comments) throws 
IOException


I don't think two methods are needed, its easy enough for the caller to 
adapt an OutputStream to a Writer
(OutputStreamWriter) and take control of the encoding, so the 
OutputStream version is not essential.




For the sake of this discussion we won't be talking about the "save" 
API, in that same class, which has been deprecated.


As part of this enhancement, one of the proposed API name is 
"storeCanonical". As a start, I plan to use this name for the new API. 
Is there any different suggestion for the name?


As for the API signature, I plan to introduce 2 new APIs:

    public void storeCanonical(Writer writer, String comments) throws 
IOException
    public void storeCanonical(OutputStream out, String comments) 
throws IOException


to match what the "store" variants currently provide. The first 
difference between these "storeCanonical" and the "store" will be the 
trivial part where these new "storeCanonical" implementations will no 
longer write out the date comment. Users are allowed to pass optional 
comments to these new APIs. If any comment is passed to these APIs, 
these will continue to be written out first, before the actual 
properties are written out.

'storeCanonical' captures the semantics.


Speaking of optional comments, should the APIs accept an instance of 
java.util.Optional for the comments parameter. Perhaps:


    public void storeCanonical(Writer writer, Optional 
comments) throws IOException
    public void storeCanonical(OutputStream out, Optional 
comments) throws IOException


Optional is overkill here, using null for no comment is conventional and 
matches the current usage

in the store(..) methods.



Coming to the part where we write out the properties, these APIs will 
write out the properties in the lexicographical order of the property 
keys. An additional enhancement perhaps could be to allow users to 
pass in an optional java.util.Comparator instance to provide for 
application specific ordering of the property keys while being written 
out by these APIs. I am not too sure if we should introduce that. Any 
inputs? If we do introduce it, we would end up with 4 new APIs:


    public void storeCanonical(Writer writer, Optional 
comments) throws IOException
    public void storeCanonical(OutputStream out, Optional 
comments) throws IOException
    public void storeCanonical(Writer writer, Optional 
comments, Comparator keyOrderer) throws IOException
    public void storeCanonical(OutputStream out, Optional 
comments, Comparator keyOrderer) throws IOException
Canonical usually already means a non-variable encoding, that seems the 
inconsistent with

providing a Comparator.

However, it should be a goal that properties stored with storeCanonical 
can be

loaded with load().



Is that worth it?

Finally, the other semantics, like the property key value separators, 
how/where newlines are inserted, what character encoding is used 
etc... will continue to match with the current semantics of the 
"store" APIs.


If a client has the need for a custom format, its quite easy to iterate 
over the contents,

sorting if desires and writing the format itself.
A custom format would not be usable with Properties.load.

Simpler is better,

I think a single new method should suffice.

Thanks, Roger




[1] https://bugs.openjdk.java.net/browse/JDK-8231640

-Jaikiran

Re: Dangling class-level javadoc comments in JDK

[Jonathan Gibbons]

IIRC, the one in javadoc CommentUtils has recently been fixed.

It might be worth a javac -Xlint option to detect/report such dangling 
comments.


-- Jon

On 8/23/21 11:50 PM, Andrey Turbanov wrote:

Hello.
I found a few internal classes in the JDK codebase which don't have
proper javadoc, but have dangling javadoc-like comments.
Dangling Javadoc comments are ignored by the javadoc tool and IDE.
Perhaps it was intentional to not add proper javadoc to them?
I believe it's better to convert them to proper javadoc to make
developing JDK a bit more friendly within IDE.
What do you think?

List of classes:

com.sun.beans.editors.BooleanEditor
com.sun.beans.editors.ByteEditor
com.sun.beans.editors.DoubleEditor
com.sun.beans.editors.FloatEditor
com.sun.beans.editors.IntegerEditor
com.sun.beans.editors.LongEditor
com.sun.beans.editors.NumberEditor
com.sun.beans.editors.ShortEditor
com.sun.jndi.toolkit.dir.ContainmentFilter
com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl
com.sun.security.auth.module.Crypt
java.math.MutableBigInteger
java.net.DefaultInterface
javax.swing.GraphicsWrapper
jdk.internal.access.JavaAWTFontAccess
jdk.javadoc.internal.doclets.toolkit.CommentUtils
sun.awt.X11.XAtom
sun.awt.X11.XAwtState
sun.java2d.xr.XRBackend
sun.java2d.xr.XRDrawLine
sun.jvm.hotspot.debugger.PageCache
sun.jvm.hotspot.runtime.JavaThreadFactory
sun.jvm.hotspot.utilities.Interval
sun.jvm.hotspot.utilities.MessageQueueBackend
sun.jvm.hotspot.utilities.RBTree
sun.launcher.LauncherHelper
sun.net.www.content.text.plain
sun.net.www.protocol.file.FileURLConnection
sun.nio.ch.Interruptible
sun.security.pkcs.ParsingException
sun.security.provider.SeedGenerator
sun.security.util.ByteArrayTagOrder
sun.security.util.IOUtils


Andrey Turbanov

Re: RFR: 8272347: ObjectMethods::bootstrap should specify NPE if any argument except lookup is null [v2]

[Chris Hegarty]

On Tue, 24 Aug 2021 03:03:48 GMT, Vicente Romero  wrote:

>> Please review this simple PR along with the associated CSR. The PR is 
>> basically adding a line the the specification of method 
>> `java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a 
>> NPE will be thrown.
>> 
>> TIA
>> 
>> link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852)
>
> Vicente Romero has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   addressing review comments

Marked as reviewed by chegar (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5226

Proposal: JDK-8231640 - (prop) Canonical property storage

[Jaikiran Pai]

The java.util.Properties class allows the properties to be written out 
to a stream or through a writer. In its current form, the specification 
of these APIs state that a comment comprising of the current date is 
always written out. The spec doesn't make any guarantees about the order 
of the properties when they are written out.


There have been requests asking to make these APIs more deterministic. 
These requests, from what I have seen, mainly ask for:


- A way to disable writing out the date comment
- A way to write out the properties in a deterministic and reproducible way

There have been discussions in the mailing list in the past which have 
been captured in JDK-8231640[1]. In these discussions, there has been an 
inclination to not touch the current existing API implementations and 
instead introduce new API(s) to achieve the proposed use cases.


Before starting off with an implementation, I wanted to try and get some 
inputs on what the new API(s) would look like and what the scope of such 
a work should be.


Right now, the Properties class has 2 "store" APIs:

    public void store(Writer writer, String comments) throws IOException
    public void store(OutputStream out, String comments) throws IOException

For the sake of this discussion we won't be talking about the "save" 
API, in that same class, which has been deprecated.


As part of this enhancement, one of the proposed API name is 
"storeCanonical". As a start, I plan to use this name for the new API. 
Is there any different suggestion for the name?


As for the API signature, I plan to introduce 2 new APIs:

    public void storeCanonical(Writer writer, String comments) throws 
IOException
    public void storeCanonical(OutputStream out, String comments) 
throws IOException


to match what the "store" variants currently provide. The first 
difference between these "storeCanonical" and the "store" will be the 
trivial part where these new "storeCanonical" implementations will no 
longer write out the date comment. Users are allowed to pass optional 
comments to these new APIs. If any comment is passed to these APIs, 
these will continue to be written out first, before the actual 
properties are written out.


Speaking of optional comments, should the APIs accept an instance of 
java.util.Optional for the comments parameter. Perhaps:


    public void storeCanonical(Writer writer, Optional 
comments) throws IOException
    public void storeCanonical(OutputStream out, Optional 
comments) throws IOException



Coming to the part where we write out the properties, these APIs will 
write out the properties in the lexicographical order of the property 
keys. An additional enhancement perhaps could be to allow users to pass 
in an optional java.util.Comparator instance to provide for application 
specific ordering of the property keys while being written out by these 
APIs. I am not too sure if we should introduce that. Any inputs? If we 
do introduce it, we would end up with 4 new APIs:


    public void storeCanonical(Writer writer, Optional 
comments) throws IOException
    public void storeCanonical(OutputStream out, Optional 
comments) throws IOException
    public void storeCanonical(Writer writer, Optional 
comments, Comparator keyOrderer) throws IOException
    public void storeCanonical(OutputStream out, Optional 
comments, Comparator keyOrderer) throws IOException


Is that worth it?

Finally, the other semantics, like the property key value separators, 
how/where newlines are inserted, what character encoding is used etc... 
will continue to match with the current semantics of the "store" APIs.



[1] https://bugs.openjdk.java.net/browse/JDK-8231640

-Jaikiran

Re: JPackage and ask for microphone permissions broken on OSX...

[Andy Herrick]

On 8/24/2021 6:08 AM, Filteredaccount1 wrote:

Hi Andy,

During the wait for JDK 18, would it be possible to describe on the bug ticket 
what manual workaround steps are required to apply to an existing jPackaged app 
for distribution both inside and outside the app store?


The instructions for working around this bug as described are in public 
comment in https://bugs.openjdk.java.net/browse/


The related app-store specific change is in the default entitlements 
file.  I will add comment to JDK-8272639. explaining how to work around 
that issue by using the --entitlements option.


There is one Info.plist for the app (.app/Contents/Info.plist) and 
another for the runtime (.app/Contents/runtime/Contents/Info.plist).


Only the first one is relevant here.  The key 
NSMicrophoneUsageDescription belongs in the entitlements file 
(not the Info.plist).


The default entitlements file for an app-store targeted app is 
src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/sandbox.plist 
, 
but 
that can be overridden using the --mac-entitlements option.


One final thing to note, MacOS keeps track of what you have ever 
previously granted microphone permission to (and will never ask again) 
based on the mac package identifier (which defaults to the main class 
name), so I explicitly set this using a shell script with jpackage 
option "--mac-package-identifier audio-$1" option, so I can pass in 
different values and create a unique one each time.


Hope this helps.

/Andy



There are two info.plist files inside a jPackaged app. In my experience adding 
keys to both didn’t turn the ask microphone permissions on.

com.apple.security.device.audio-input


The application is requesting access to the microphone.

Also, I raised at http://bugreport.java.com/ 9071230. So developer time isn’t 
wasted, could this be cancelled? (seems setup so the general public cannot).


I can't see this issue, so it must already have been removed.

/Andy



Thank You,

Ben S.



Date: Wed, 18 Aug 2021 08:43:08 -0400
From: Andy Herrick 
To: core-libs-dev@openjdk.java.net
Subject: Re: JPackage and ask for microphone permissions broken on
OSX...
Message-ID: <1534b02b-262a-f338-aae5-d1693d007...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

OK - I have reproduced this problem, filed an issue, and found the fix.

You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639.

Basically another key is needed in application plist to cause
application to ask for microphone access.

It is far to late to get any fix into JDK17, but I will fix in JDK18 and
you can work around this issue in JDK17 (or JDK16) by using the
--resource-dir option:

Re: RFR: 8247980: Exclusive execution of java/util/stream tests slows down tier1

[Christoph Langer]

On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev  wrote:

> See the bug report for more details. I would appreciate if people with their 
> corporate testing systems would run this through their systems to avoid 
> surprises. (ping @RealCLanger, @iignatev).

I have added this to our internal testing, let's see how it goes. Notifying 
@ArnoZeller about this.

-

PR: https://git.openjdk.java.net/jdk/pull/5189

Re: RFR: 8266936: Add a finalization JFR event [v9]

[Markus Grönlund]

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to 
> replace and mitigate Object.finalize() uses in the JDK libraries; please see 
> https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which 
> classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Grönlund has updated the pull request incrementally with one additional 
commit since the last revision:

  Model as finalizerService

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/5da3bb89..e6b786f1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4731=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4731=07-08

  Stats: 1153 lines in 13 files changed: 578 ins; 555 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Alexander Zvegintsev]

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov 
 wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

There are a bunch of calls to `Collections.sort()` without a comparator 
specified  (at least in java.desktop):

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/Spans.java#L144
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/DebugSettings.java#L278
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java#L787
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1070
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java#L1204
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/GroupLayout.java#L2137

It is also a wrapper to `list.sort(null)`. 

Is there any reason to not touch them along with this fix?

-

PR: https://git.openjdk.java.net/jdk/pull/5229

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Daniel Fuchs]

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov 
 wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

java/net and sun/net changes LGTM

-

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5229

Re: Dangling class-level javadoc comments in JDK

[Alan Bateman]

On 24/08/2021 07:50, Andrey Turbanov wrote:

Hello.
I found a few internal classes in the JDK codebase which don't have
proper javadoc, but have dangling javadoc-like comments.
Dangling Javadoc comments are ignored by the javadoc tool and IDE.
Perhaps it was intentional to not add proper javadoc to them?
I believe it's better to convert them to proper javadoc to make
developing JDK a bit more friendly within IDE.
What do you think?
There isn't any requirement for internal classes to have complete 
javadoc. If there are cases in the list where fleshing out or fixing 
javadoc issues would help future maintainers then go ahead. Looking at 
your list then I assume some of these are just noise and not worth doing 
anything.


-Alan

Re: RFR: 8264322: Generate CDS archive when creating custom JDK image [v2]

[Alan Bateman]

On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung  wrote:

>> Please review this change for adding a `jlink` command line option 
>> `--generate-cds-archive` for generating CDS archives as a post processing 
>> step during the creation of a custom JDK image.
>> 
>> Details can be found in the corresponding CSR 
>> [JDK-8269178](https://bugs.openjdk.java.net/browse/JDK-8269178).
>> 
>> Testing:
>> 
>> - [x] tiers 1,2 (including the new test)
>
> Calvin Cheung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   @mlchung comments

This looks okay, and I see a follow-on issue has been created for the test 
improvements.

-

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5174

Withdrawn: JDK-8267936: PreserveAllAnnotations option isn't tested

[duke]

On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach 
 wrote:

> There doesn't seem to be much support for the complete changes in #4245. To 
> get at least something useful from that endeavor I have extracted the test 
> for existing behavior of `-XX:+PreserveAllAnnotations` and I am offering it 
> in this pull request without any changes to the JVM behavior.

This pull request has been closed without being integrated.

-

PR: https://git.openjdk.java.net/jdk/pull/4280

Re: RFR: 8272861: Add a micro benchmark for vector api

[Aleksey Shipilev]

On Mon, 23 Aug 2021 23:18:28 GMT, Sandhya Viswanathan 
 wrote:

> This pull request adds a micro benchmark for Vector API.
> The Black Scholes algorithm is implemented with and without Vector API.
> We see about ~6x gain with Vector API for this micro benchmark using 256 bit 
> vectors.

Some benchmark comments.

test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java line 91:

> 89: static float A4 = -1.821255978f;
> 90: static float A5 = 1.330274429f;
> 91: static float PI = (float)Math.PI;

Want to make these `static final`?

test/micro/org/openjdk/bench/jdk/incubator/vector/BlackScholes.java line 134:

> 132: 
> 133: @Benchmark
> 134: public void scalar_black_scholes(Blackhole bh) {

So there is a `Blackhole` argument here, but what is actually blackholed? 
AFAICS, stores to `call` and `put` are roughly okay to avoid dead-code 
elimination on these paths.

-

PR: https://git.openjdk.java.net/jdk/pull/5234

Re: JPackage and ask for microphone permissions broken on OSX...

[Filteredaccount1]

Hi Andy,

During the wait for JDK 18, would it be possible to describe on the bug ticket 
what manual workaround steps are required to apply to an existing jPackaged app 
for distribution both inside and outside the app store?

There are two info.plist files inside a jPackaged app. In my experience adding 
keys to both didn’t turn the ask microphone permissions on.

com.apple.security.device.audio-input

NSMicrophoneUsageDescription
The application is requesting access to the microphone.

Also, I raised at http://bugreport.java.com/ 9071230. So developer time isn’t 
wasted, could this be cancelled? (seems setup so the general public cannot).

Thank You,

Ben S.


> Date: Wed, 18 Aug 2021 08:43:08 -0400
> From: Andy Herrick 
> To: core-libs-dev@openjdk.java.net
> Subject: Re: JPackage and ask for microphone permissions broken on
>OSX...
> Message-ID: <1534b02b-262a-f338-aae5-d1693d007...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> OK - I have reproduced this problem, filed an issue, and found the fix.
> 
> You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639.
> 
> Basically another key is needed in application plist to cause 
> application to ask for microphone access.
> 
> It is far to late to get any fix into JDK17, but I will fix in JDK18 and 
> you can work around this issue in JDK17 (or JDK16) by using the 
> --resource-dir option:

Dangling class-level javadoc comments in JDK

[Andrey Turbanov]

Hello.
I found a few internal classes in the JDK codebase which don't have
proper javadoc, but have dangling javadoc-like comments.
Dangling Javadoc comments are ignored by the javadoc tool and IDE.
Perhaps it was intentional to not add proper javadoc to them?
I believe it's better to convert them to proper javadoc to make
developing JDK a bit more friendly within IDE.
What do you think?

List of classes:

com.sun.beans.editors.BooleanEditor
com.sun.beans.editors.ByteEditor
com.sun.beans.editors.DoubleEditor
com.sun.beans.editors.FloatEditor
com.sun.beans.editors.IntegerEditor
com.sun.beans.editors.LongEditor
com.sun.beans.editors.NumberEditor
com.sun.beans.editors.ShortEditor
com.sun.jndi.toolkit.dir.ContainmentFilter
com.sun.jndi.toolkit.dir.LazySearchEnumerationImpl
com.sun.security.auth.module.Crypt
java.math.MutableBigInteger
java.net.DefaultInterface
javax.swing.GraphicsWrapper
jdk.internal.access.JavaAWTFontAccess
jdk.javadoc.internal.doclets.toolkit.CommentUtils
sun.awt.X11.XAtom
sun.awt.X11.XAwtState
sun.java2d.xr.XRBackend
sun.java2d.xr.XRDrawLine
sun.jvm.hotspot.debugger.PageCache
sun.jvm.hotspot.runtime.JavaThreadFactory
sun.jvm.hotspot.utilities.Interval
sun.jvm.hotspot.utilities.MessageQueueBackend
sun.jvm.hotspot.utilities.RBTree
sun.launcher.LauncherHelper
sun.net.www.content.text.plain
sun.net.www.protocol.file.FileURLConnection
sun.nio.ch.Interruptible
sun.security.pkcs.ParsingException
sun.security.provider.SeedGenerator
sun.security.util.ByteArrayTagOrder
sun.security.util.IOUtils


Andrey Turbanov

Re: RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Sergey Bylokhov]

On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov 
 wrote:

> Collections.sort is just a wrapper, so it is better to use an instance method 
> directly.

The changes in the src/java.desktop/ looks fine.

Filed: https://bugs.openjdk.java.net/browse/JDK-8272863

-

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5229

RFR: 8272863: Replace usages of Collections.sort with List.sort call in public java modules

[Andrey Turbanov]

Collections.sort is just a wrapper, so it is better to use an instance method 
directly.

-

Commit messages:
 - [PATCH] Replace usages of Collections.sort with List.sort call in public 
java modules

Changes: https://git.openjdk.java.net/jdk/pull/5229/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5229=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272863
  Stats: 27 lines in 10 files changed: 0 ins; 8 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5229/head:pull/5229

PR: https://git.openjdk.java.net/jdk/pull/5229