Re: RFR: JDK-8230521: rename --output/-o option and add default value (".")

[Alexey Semenyuk]

On 9/12/2019 10:47 PM, Alexey Semenyuk wrote:
http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html: 


---
126 Path destPath = Paths.get(".").toAbsolutePath();
 127 if (destPath.getFileName().toString().equals(".")) {
 128 dest = destPath.getParent().toString();
 129 } else {
 130 dest = destPath.toString();
 131 }
---
Are you trying to get rid of trailing "." path component in the above 
code fragment? If yes, then this can be simplified as follows:

---
Path destPath = Paths.get(".").normalize().toAbsolutePath();
---

Or even simpler:
---
Path destPath = Paths.get("").toAbsolutePath();
---

- Alexey


In general I don't like the idea of renaming variables and method 
names from `output` to `dest`. This doesn't add much value to the code 
and is incomplete and thus confusing (e.g.: in all the tests OUTPUT 
variable remains unnamed).

I suggest to change only `--output` to `--dest` tokens in the code.

Slightly unrelated thing. macOS tests
---
test/jdk/tools/jpackage/macosx/base/Base.java
test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java
test/jdk/tools/jpackage/macosx/base/InstallDirBase.java
test/jdk/tools/jpackage/macosx/base/LicenseBase.java
---
duplicate corresponding shared tests that have been added in the patch 
for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't touch 
them as I didn't have MAC to try the replacements. Could you please 
just drop these obsolete tests and also run the new tests to make sure 
they work as expected. I mean not just run the tests to create package 
bundles, but also install these bundles and run the tests in a mode 
when they verify packages are properly installed.


- Alexey

On 9/12/2019 9:34 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Renamed "--output" to "--dest" and made it optional with default to 
".".


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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230521: rename --output/-o option and add default value (".")

[Alexey Semenyuk]

http://cr.openjdk.java.net/~almatvee/8230521/webrev.00/src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java.sdiff.html:
---
126 Path destPath = Paths.get(".").toAbsolutePath();
 127 if (destPath.getFileName().toString().equals(".")) {
 128 dest = destPath.getParent().toString();
 129 } else {
 130 dest = destPath.toString();
 131 }
---
Are you trying to get rid of trailing "." path component in the above 
code fragment? If yes, then this can be simplified as follows:

---
Path destPath = Paths.get(".").normalize().toAbsolutePath();
---

In general I don't like the idea of renaming variables and method names 
from `output` to `dest`. This doesn't add much value to the code and is 
incomplete and thus confusing (e.g.: in all the tests OUTPUT variable 
remains unnamed).

I suggest to change only `--output` to `--dest` tokens in the code.

Slightly unrelated thing. macOS tests
---
test/jdk/tools/jpackage/macosx/base/Base.java
test/jdk/tools/jpackage/macosx/base/FileAssociationsBase.java
test/jdk/tools/jpackage/macosx/base/InstallDirBase.java
test/jdk/tools/jpackage/macosx/base/LicenseBase.java
---
duplicate corresponding shared tests that have been added in the patch 
for https://bugs.openjdk.java.net/browse/JDK-8230726. I didn't touch 
them as I didn't have MAC to try the replacements. Could you please just 
drop these obsolete tests and also run the new tests to make sure they 
work as expected. I mean not just run the tests to create package 
bundles, but also install these bundles and run the tests in a mode when 
they verify packages are properly installed.


- Alexey

On 9/12/2019 9:34 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Renamed "--output" to "--dest" and made it optional with default to 
".".


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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

RFR: JDK-8230521: rename --output/-o option and add default value (".")

[Alexander Matveev]

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Renamed "--output" to "--dest" and made it optional with default to ".".

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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR 8230937 : Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java

[David Holmes]

Looks good.

Thanks for updating.

David

On 13/09/2019 9:02 am, Brent Christian wrote:

Hi,

 From the bug report:

"The ProblemList indicates that 
vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to 
JDK-8212117. That bug has been fixed, but this test still fails. That 
line in the ProblemList should instead use 8221503."


The change is:

diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt    Thu Sep 12 09:59:19 2019 -0700
+++ b/test/hotspot/jtreg/ProblemList.txt    Thu Sep 12 15:52:07 2019 -0700
@@ -167,7 +167,7 @@

vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
8065773 generic-all


-vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all
+vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all

  vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
generic-all


Thanks,
-Brent

Re: RFR 8230937 : Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java

[Mandy Chung]

+1
Mandy

On 9/12/19 4:02 PM, Brent Christian wrote:

Hi,

From the bug report:

"The ProblemList indicates that 
vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to 
JDK-8212117. That bug has been fixed, but this test still fails. That 
line in the ProblemList should instead use 8221503."


The change is:

diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt    Thu Sep 12 09:59:19 2019 
-0700
+++ b/test/hotspot/jtreg/ProblemList.txt    Thu Sep 12 15:52:07 2019 
-0700

@@ -167,7 +167,7 @@

vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
8065773 generic-all


-vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all
+vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all

 vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
generic-all


Thanks,
-Brent

RFR 8230937 : Update bugid in ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java

[Brent Christian]

Hi,

From the bug report:

"The ProblemList indicates that 
vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to 
JDK-8212117. That bug has been fixed, but this test still fails. That 
line in the ProblemList should instead use 8221503."


The change is:

diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txtThu Sep 12 09:59:19 2019 -0700
+++ b/test/hotspot/jtreg/ProblemList.txtThu Sep 12 15:52:07 2019 -0700
@@ -167,7 +167,7 @@

vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
8065773 generic-all


-vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all
+vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all

 vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
generic-all


Thanks,
-Brent

Re: RFR: JDK-8230629: jpackage signing on macOS does not work as expected

[Andy Herrick]

looks good.

/Andy

On 9/12/2019 5:44 PM, Alexander Matveev wrote:

Hi Alexey,

http://cr.openjdk.java.net/~almatvee/8230629/webrev.01
I simplified isFileSigned() as you suggested.

Thanks,
Alexander

On 9/12/2019 4:13 AM, Alexey Semenyuk wrote:

Looks good, though
---
List args = new ArrayList<>();
 940 args.addAll(Arrays.asList("codesign",
 941 "--verify",
 942 file.toString()));
 943
 944 ProcessBuilder pb
 945 = new ProcessBuilder(args.toArray(new 
String[args.size()]));

---

can be as simple as:
---
ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", 
file.toString());

---

- Alexey

On 9/11/2019 11:53 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Binaries in runtime and Frameworks will not be signed directly 
using user provided certificate.
- libapplauncher.dylib will be signed with user provided certificate 
only if it is unsigned.
- When signing is enabled app and pkg will be signed, but not dmg. 
App inside pkg and dmg will be signed as well.


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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230629: jpackage signing on macOS does not work as expected

[Alexey Semenyuk]

Thank you, looks good.

- Alexey

On 9/12/2019 5:44 PM, Alexander Matveev wrote:

Hi Alexey,

http://cr.openjdk.java.net/~almatvee/8230629/webrev.01
I simplified isFileSigned() as you suggested.

Thanks,
Alexander

On 9/12/2019 4:13 AM, Alexey Semenyuk wrote:

Looks good, though
---
List args = new ArrayList<>();
 940 args.addAll(Arrays.asList("codesign",
 941 "--verify",
 942 file.toString()));
 943
 944 ProcessBuilder pb
 945 = new ProcessBuilder(args.toArray(new 
String[args.size()]));

---

can be as simple as:
---
ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", 
file.toString());

---

- Alexey

On 9/11/2019 11:53 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Binaries in runtime and Frameworks will not be signed directly 
using user provided certificate.
- libapplauncher.dylib will be signed with user provided certificate 
only if it is unsigned.
- When signing is enabled app and pkg will be signed, but not dmg. 
App inside pkg and dmg will be signed as well.


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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230629: jpackage signing on macOS does not work as expected

[Alexander Matveev]

Hi Alexey,

http://cr.openjdk.java.net/~almatvee/8230629/webrev.01
I simplified isFileSigned() as you suggested.

Thanks,
Alexander

On 9/12/2019 4:13 AM, Alexey Semenyuk wrote:

Looks good, though
---
List args = new ArrayList<>();
 940 args.addAll(Arrays.asList("codesign",
 941 "--verify",
 942 file.toString()));
 943
 944 ProcessBuilder pb
 945 = new ProcessBuilder(args.toArray(new 
String[args.size()]));

---

can be as simple as:
---
ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", 
file.toString());

---

- Alexey

On 9/11/2019 11:53 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Binaries in runtime and Frameworks will not be signed directly 
using user provided certificate.
- libapplauncher.dylib will be signed with user provided certificate 
only if it is unsigned.
- When signing is enabled app and pkg will be signed, but not dmg. 
App inside pkg and dmg will be signed as well.


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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8229779: Shortcut creation policy

[Alexander Matveev]

Looks good.

Thanks,
Alexander

On 9/12/2019 4:11 AM, Andy Herrick wrote:

Revised with webrev.03.

Changed SimplePackageTest instructions as suggested and added 
LinuxDebBundler.java to file list (double checked file list used to 
create webrev contains all changed files).


/ANdy

On 9/11/2019 10:09 PM, Alexey Semenyuk wrote:

SimplePackageTest.java:
I'd suggest to put "Installer should not create any shortcuts" in the 
description or simply remove notice about shortcuts.


Did you omit adding shortcuts to LinuxDebBundler.java on purpose?

- Alexey

On 9/11/2019 9:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

1.) adds the new option --linux-shortcut, and now only creates a 
shortcut on linux if specified


2.) only creates a shortcut on windows if win-menu or win-shortcut 
is specified.


/Andy


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

[2] http://cr.openjdk.java.net/~herrick/8229779

Re: 8229471: Calendar under a specific timezone changes HOUR field when MILLISECOND field is changed

[naoto . sato]

Hi Masanori,

Thank you for looking at the issue and your contribution. I am also  
investigating it (as an assignee of the bug), and looking at this old  
issue:


https://bugs.openjdk.java.net/browse/JDK-4177484

The comment suggests that the existing behavior is the expected one. In  
fact, your fix would break some regression test cases in  
jdk/java/util/Calendar/CalendarRegression.java.


I will need some more archaeological investigation, but I am inclined to  
close it as not an issue at the moment.


Naoto

On 9/12/19 12:16 AM, Yano, Masanori wrote:

Hello.

I think JDK-8229471 occurs because a change of TimeZone is not considered in 
getTime().
To resolve this problem, isTimeSet flag must be set to false when setTimeZone() 
is called.

Please review the following change.

diff -r e1269de19aa5 src/java.base/share/classes/java/util/Calendar.java
--- a/src/java.base/share/classes/java/util/Calendar.java  Thu Aug 22 
14:09:36 2019 -0700
+++ b/src/java.base/share/classes/java/util/Calendar.java  Thu Sep 12 
11:45:37 2019 +0900
@@ -2901,7 +2901,7 @@
   * generally, a call to setTimeZone() affects calls to set() BEFORE 
AND
   * AFTER it up to the next call to complete().
   */
-areAllFieldsSet = areFieldsSet = false;
+isTimeSet = areAllFieldsSet = areFieldsSet = false;
  }

  /**
diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java
--- /dev/null  Thu Jan 01 00:00:00 1970 +
+++ b/test/jdk/java/util/Calendar/Bug8229471.java  Thu Sep 12 11:45:37 2019 
+0900
@@ -0,0 +1,22 @@
+/*
+ *@test
+ *@bug 8229471
+ *@summary test for recompute when Calendar.setTimeZone()
+ */
+
+import java.util.Calendar;
+import java.util.Date;
+import java.util.Locale;
+import java.util.TimeZone;
+
+public class Bug8229471 {
+public static void main(String[] args) throws Exception {
+Calendar calendar = Calendar.getInstance(new Locale("en", "US"));
+Date date1 = calendar.getTime();
+calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest"));
+Date date2 = calendar.getTime();
+if (date1.equals(date2)) {
+throw new RuntimeException("Bug8229471: failed. TimeZone is not 
applied.");
+}
+}
+}

Regards,
Masanori Yano

Re: RFR(s): 8228580: DnsClient TCP socket timeout

[Alan Bateman]

On 12/09/2019 12:41, Chris Hegarty wrote:
Here is an initial attempt to document these timeout/retry properties. 
It’s effectively the wording lifted from the tech notes [1], with 
“UDP” removed.

Thanks, this look and dropping the reference to "UDP" make sense.

One minor nit is that "are relevant to the DNSprovider" might be better 
worded as "may be used when creating the initial context". This will fit 
nicely if/when someone adds a description to the @provides tag. At some 
point I hope the other properties can be used too but that is beyond the 
scope of JDK-8228580.


-Alan

Re: RFR 8230829 : Matcher matches a surrogate pair that crosses border of the region

[Ivan Gerasimov]

Thank you Naoto for reviewing!

With kind regards,

Ivan

On 9/12/19 8:02 AM, naoto.s...@oracle.com wrote:

Looks good to me, Ivan.

Naoto

On 9/10/19 9:13 PM, Ivan Gerasimov wrote:

Hello!

When the regex.Matcher matches a supplementary codepoint, it may 
inadvertently cross the border of the explicitly specified region 
without noticing.


Would you please help review a simple fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230829
WEBREV: http://cr.openjdk.java.net/~igerasim/8230829/00/webrev/

Thanks in advance!




--
With kind regards,
Ivan Gerasimov

Re: Feedback JEP 343: jpackage --win-menu

[Christopher Merrill]

On Thu, Sep 12, 2019 at 11:28 AM Andy Herrick 
wrote:

> yes - clearly something wrong here - it is supposed to find
> MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it has
> come up with jvm.cfg - a completely unrelated file.
>
> lets see - your input dir is the lib dir of your runtime-image.  the app
> dir will be populated with everything in the input dir, so it gets jvm.cfg
> which is in every runtime's lib dir.
>
> Not sure why you want to do this, but I think it points out we should not
> be satisfied that a file has extension "cfg", we should also look at it and
> confirm it looks like a valid jpackage app-image .cfg file, before
> deriving the name of the app from the name of the cfg file.
>

It is entirely possible I *don't* want to do that. I'm admittedly a newbie
on this. I'm upgrading an app that used the old packager, via a Gradle
plugin, to bundles our app. I'm using a new gradle plugin that is likely
less finished, since jpackager is so new :)

I've been using https://bugs.openjdk.java.net/browse/JDK-8200758 as a
reference, but it is not clear what is and is not yet implemented, thus
far. Is there a better source for current docs?

What should the input dir point to?  Perhaps just the lib folder of my
distribution, which contains all the JARs?  (I don't need command-line
launchers).

Thanks again!
Chris



> /Andy
> On 9/12/2019 11:08 AM, Christopher Merrill wrote:
>
> Thanks Andy.
>
> Ok, so the image was created in the previous step using:
> C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input
> D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar
> MuseIDE-launcher-3.1.jar --main-class org.musetest.ide.launcher.Bootstrap
> --output D:\Work\MuseProject\ide\closed\install\build\jpackage --name
> MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap
> --runtime-image D:\Work\MuseProject\ide\closed\install\build\image
>
> There is only one .cfg file in the .../build/image folder, 'jvm.cfg',
> which contains:
> -server KNOWN
> -client IGNORE
>
> However, the output folder (../build/jpackage/MuseIDE-launcher/app) of the
> second jpackage step which I referenced in the previous message contains a
> MuseIDE-launcher.cfg file with:
> [Application]
> app.name=MuseIDE-launcher
> app.version=1.0
> app.runtime=$APPDIR\runtime
> app.identifier=org.musetest.ide.launcher.Bootstrap
>
> app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar
> app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar
> app.mainclass=org.musetest.ide.launcher.Bootstrap
> [JavaOptions]
> [ArgOptions]
>
> I didn't create or supply that file...so I assume jpackage did.
>
> Could it be the missing windows start menu item be affected by the
> location of the main class?  In my case, it isn't in the main jar. In fact,
> the main jar is empty except for the manifest, which contains only the
> manifest version declaration. The main class is located in one of the other
> jar files, which are correctly included in the resulting image and
> installer. The .cfg correctly includes those JARs on the classpath (and it
> all works fine when installed). I don't really see how that should affect
> the creation of a shortcut to the .exe, but thought I would mention it.
>
> TIA!
> Chris
>
>
>
> On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick 
> wrote:
>
>> Strange ...
>>
>> I can't seem to reproduce any scenario where msi installer created by
>> jpackage won't install a shortcut, but from the message:
>>
>> "Multiple launchers found in predefined app-image. jvm will be used as
>> primary launcher."
>>
>> It seems that  you are using a predefined app-image  and there are
>> multiple launchers in the app-image, and the code is choosing "jvm" as
>> the primary one (the one a shortcut will be created for).
>>
>> This may be the wrong launcher.  When an installer is built for an
>> existing app-image, it doesn't know the name of the app, it looks for
>> the config file  in /app/
>>
>> If there are multiple cfg files (like you built the app-image with
>> --add-launcher jvm=jvm-launcher.properties) it is just taking the first
>> one.
>>
>> Is it possible this is what is happening in your case ?
>>
>> /Andy
>>
>> On 9/12/2019 9:54 AM, Christopher Merrill wrote:
>> > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI
>> > installer. If I am understanding the comments in thread "RFR:
>> JDK-8229779:
>> > Shortcut creation policy", a start menu entry (and desktop shortcut?)
>> > should always be produced with this version of jpackage command line
>> > options? The MSI installer I've created does not create a start menu
>> entry,
>> > even when I include the --win-menu option. Other people seem to have the
>> > opposite problem (start menu item when they don't want it), so clearly
>> I'm
>> > doing something wrong...
>> >
>> > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi 

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

[Martin Buchholz]

On Thu, Sep 12, 2019 at 10:53 AM Pavel Rappo  wrote:

> Martin,
>
> May I add you to the list of people who reviewed this change? I mean the
> concurrency-related portion of the change, specifically in the test. Not
> the LDAP part.
>

Sure!

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

[Pavel Rappo]

Martin, 

May I add you to the list of people who reviewed this change? I mean the 
concurrency-related portion of the change, specifically in the test. Not the 
LDAP part.

> On 12 Sep 2019, at 16:21, Martin Buchholz  wrote:
> 
> 
> 
> On Thu, Sep 12, 2019 at 4:36 AM Pavel Rappo  wrote:
> 
> I should have expressed myself more clear. I meant that the main thread and 
> the thread created (and started) by `newStartedThread` (the test tread) do 
> not wait for *each other* before they begin. This might be needed to make 
> sure that they start at the same time (loosely speaking, of course). One 
> might argue that the importance of this diminishes with the increase of the 
> timeout that the main thread uses to wait for the test thread to die and the 
> accuracy of measurements one agrees to tolerate.
> 
> 
> You want coordination?  We got coordination.
> 
> Here's some infrastructure that uses a threadsStarted latch:
> 
> void assertThrowInterruptedExceptionWhenInterrupted(Action[] actions) {
> int n = actions.length;
> Future[] futures = new Future[n];
> CountDownLatch threadsStarted = new CountDownLatch(n);
> CountDownLatch done = new CountDownLatch(n);
> 
> for (int i = 0; i < n; i++) {
> Action action = actions[i];
> futures[i] = cachedThreadPool.submit(new CheckedRunnable() {
> public void realRun() throws Throwable {
> threadsStarted.countDown();
> try {
> action.run();
> shouldThrow();
> }
> catch (InterruptedException success) {}
> catch (Throwable fail) { threadUnexpectedException(fail); 
> }
> assertFalse(Thread.interrupted());
> done.countDown();
> }});
> }
> 
> await(threadsStarted);
> assertEquals(n, done.getCount());
> for (Future future : futures) // Interrupt all the tasks
> future.cancel(true);
> await(done);
> }
> 
> When communicating a request, just like in real life, you can't force others 
> to do anything, so be politely Canadian and use "please" in the name of your 
> latch
> 
> /**
>  * await throws InterruptedException if interrupted before counted down
>  */
> public void testAwait_Interruptible() {
> final CountDownLatch l = new CountDownLatch(1);
> final CountDownLatch pleaseInterrupt = new CountDownLatch(1);
> Thread t = newStartedThread(new CheckedRunnable() {
> public void realRun() throws InterruptedException {
> Thread.currentThread().interrupt();
> try {
> l.await();
> shouldThrow();
> } catch (InterruptedException success) {}
> assertFalse(Thread.interrupted());
> 
> pleaseInterrupt.countDown();
> try {
> l.await();
> shouldThrow();
> } catch (InterruptedException success) {}
> assertFalse(Thread.interrupted());
> 
> assertEquals(1, l.getCount());
> }});
> 
> await(pleaseInterrupt);
> if (randomBoolean()) assertThreadBlocks(t, Thread.State.WAITING);
> t.interrupt();
> awaitTermination(t);
> }
>  

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

[Daniel Fuchs]

Hi Pavel,

The changes in webrev.02 look good to me as well.
Thanks for renaming the constants in the test (I mean
TOLERANCE vs RIGHT_MARGIN and LEFT_MARGIN)  - that makes
for a much better read.

best regards,

-- daniel

On 12/09/2019 13:26, Rob McKenna wrote:

Here's the updated version of the RFR based on the discussion so far:

 http://cr.openjdk.java.net/~prappo/8151678/webrev.02/

For the reviewers. I totally forgot to explain why there's a multiplier of 2 in 
some of the timeout calculations. The reason is the current behavior of 
InitialDirContext. The supplied connect timeout seems to be used twice. Once 
for making the actual TCP connection [1] and the second time while waiting for 
the server to respond to the BIND message [2]. Thus, the total time spent in 
that InitialDirContext ctor may be twice the expected. I believe it's a bug, 
but the bug that is not related to the issue in question. The current issue 
(8151678) is about intermittent failures of LdapTimeoutTest.

-Pavel

---
[1]http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296,http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320
[2]http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154,http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365

Re: RFR: 8223490: Optimize search algorithm for determining default time zone

[naoto . sato]

Hi Seán,

I like your approach to provide the fast path to determine the system 
time zone. One general question is, is UTC/GMT the right set of fast 
path candidates? Should we add some more common ones?


Other comments to the code:

TimeZone_md.c

- Should fast path search come after "dir" validation, i.e., line 146-148?
- Line 126: "statbuf" can be removed.
- Line 134: 'i' is not size_of_something, so 'int' type should suffice 
(and its initialization is done in the for-loop).
- Line 138: the fast path search should "continue" with the next name, 
instead of "break".

- Line 142, 182: I'd wrap this line with parens for the if statement.
- Line 232-242: "pathname" is an argument to this function, so freeing 
it inside the function seems odd. Also, no need to reset dbuf/fd since 
they are no longer reused in the loop.


Naoto

On 9/11/19 3:50 AM, Seán Coffey wrote:
The current algorithm for determining the default timezone on (non-AIX) 
unix systems goes something like :


1. If TZ environment variable is defined, use it
2. else if /etc/timezone exists, use the value contained within it
3. else if /etc/localtime exists and is a symbolic link, use the name 
pointed to
4. else if /etc/localtime is a binary, find the first identical time 
zone binary file in /usr/share/zoneinfo/


Step 4 is a bit crude in that the zoneinfo directory can contain over 
1,800 files on today's systems. I'd like to change the logic so that 
common timezones are first checked for buffer matching before a full 
directory traversal is performed. It should be a performance gain and it 
should also lead to more consistent results for reasons outlined in the 
bug report.


https://bugs.openjdk.java.net/browse/JDK-8223490
webrev: http://cr.openjdk.java.net/~coffeys/webrev.8223490/webrev/ 

Re: Feedback JEP 343: jpackage --win-menu

[Andy Herrick]

I filed https://bugs.openjdk.java.net/browse/JDK-8230920 to fix this.

/Andy

On 9/12/2019 11:26 AM, Andy Herrick wrote:
yes - clearly something wrong here - it is supposed to find 
MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it 
has come up with jvm.cfg - a completely unrelated file.


lets see - your input dir is the lib dir of your runtime-image. the 
app dir will be populated with everything in the input dir, so it gets 
jvm.cfg which is in every runtime's lib dir.


Not sure why you want to do this, but I think it points out we should 
not be satisfied that a file has extension "cfg", we should also look 
at it and confirm it looks like a valid jpackage app-image .cfg 
file, before deriving the name of the app from the name of the cfg file.


/Andy

On 9/12/2019 11:08 AM, Christopher Merrill wrote:

Thanks Andy.

Ok, so the image was created in the previous step using:
C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input 
D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar 
MuseIDE-launcher-3.1.jar --main-class 
org.musetest.ide.launcher.Bootstrap --output 
D:\Work\MuseProject\ide\closed\install\build\jpackage --name 
MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap 
--runtime-image D:\Work\MuseProject\ide\closed\install\build\image


There is only one .cfg file in the .../build/image folder, 'jvm.cfg', 
which contains:

-server KNOWN
-client IGNORE

However, the output folder (../build/jpackage/MuseIDE-launcher/app) 
of the second jpackage step which I referenced in the previous 
message contains a MuseIDE-launcher.cfg file with:

[Application]
app.name =MuseIDE-launcher
app.version=1.0
app.runtime=$APPDIR\runtime
app.identifier=org.musetest.ide.launcher.Bootstrap
app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar 


app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar
app.mainclass=org.musetest.ide.launcher.Bootstrap
[JavaOptions]
[ArgOptions]

I didn't create or supply that file...so I assume jpackage did.

Could it be the missing windows start menu item be affected by the 
location of the main class?  In my case, it isn't in the main jar. In 
fact, the main jar is empty except for the manifest, which contains 
only the manifest version declaration. The main class is located in 
one of the other jar files, which are correctly included in the 
resulting image and installer. The .cfg correctly includes those JARs 
on the classpath (and it all works fine when installed). I don't 
really see how that should affect the creation of a shortcut to the 
.exe, but thought I would mention it.


TIA!
Chris



On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick 
mailto:andy.herr...@oracle.com>> wrote:


    Strange ...

    I can't seem to reproduce any scenario where msi installer 
created by

    jpackage won't install a shortcut, but from the message:

    "Multiple launchers found in predefined app-image. jvm will be
    used as
    primary launcher."

    It seems that  you are using a predefined app-image  and there are
    multiple launchers in the app-image, and the code is choosing
    "jvm" as
    the primary one (the one a shortcut will be created for).

    This may be the wrong launcher.  When an installer is built for an
    existing app-image, it doesn't know the name of the app, it looks 
for

    the config file  in /app/

    If there are multiple cfg files (like you built the app-image with
    --add-launcher jvm=jvm-launcher.properties) it is just taking the
    first one.

    Is it possible this is what is happening in your case ?

    /Andy

    On 9/12/2019 9:54 AM, Christopher Merrill wrote:
    > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build
    an MSI
    > installer. If I am understanding the comments in thread "RFR:
    JDK-8229779:
    > Shortcut creation policy", a start menu entry (and desktop
    shortcut?)
    > should always be produced with this version of jpackage command 
line

    > options? The MSI installer I've created does not create a start
    menu entry,
    > even when I include the --win-menu option. Other people seem to
    have the
    > opposite problem (start menu item when they don't want it), so
    clearly I'm
    > doing something wrong...
    >
    > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output
    > D:\Work\MuseProject\ide\closed\install\build\jpackage --name
    > MuseIDE-launcher --app-image
    >
D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher
    > --win-per-user-install --win-menu --app-version 3.1 --name
    MuseIDE-Launcher
    >
    > Other than this message, which I assume is a warning, the
    execution is
    > successful:
    >    Multiple launchers found in predefined app-image. jvm will be
    used as
    > primary launcher.
    >
    > Are there other options that would influence getting a 

Re: Feedback JEP 343: jpackage --win-menu

[Andy Herrick]

yes - clearly something wrong here - it is supposed to find 
MuseIDE-launcher.cfg and create shortcut to MuseIDE-launcher - but it 
has come up with jvm.cfg - a completely unrelated file.


lets see - your input dir is the lib dir of your runtime-image. the app 
dir will be populated with everything in the input dir, so it gets 
jvm.cfg which is in every runtime's lib dir.


Not sure why you want to do this, but I think it points out we should 
not be satisfied that a file has extension "cfg", we should also look at 
it and confirm it looks like a valid jpackage app-image .cfg file, 
before deriving the name of the app from the name of the cfg file.


/Andy

On 9/12/2019 11:08 AM, Christopher Merrill wrote:

Thanks Andy.

Ok, so the image was created in the previous step using:
C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input 
D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar 
MuseIDE-launcher-3.1.jar --main-class 
org.musetest.ide.launcher.Bootstrap --output 
D:\Work\MuseProject\ide\closed\install\build\jpackage --name 
MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap 
--runtime-image D:\Work\MuseProject\ide\closed\install\build\image


There is only one .cfg file in the .../build/image folder, 'jvm.cfg', 
which contains:

-server KNOWN
-client IGNORE

However, the output folder (../build/jpackage/MuseIDE-launcher/app) of 
the second jpackage step which I referenced in the previous message 
contains a MuseIDE-launcher.cfg file with:

[Application]
app.name =MuseIDE-launcher
app.version=1.0
app.runtime=$APPDIR\runtime
app.identifier=org.musetest.ide.launcher.Bootstrap
app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar
app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar
app.mainclass=org.musetest.ide.launcher.Bootstrap
[JavaOptions]
[ArgOptions]

I didn't create or supply that file...so I assume jpackage did.

Could it be the missing windows start menu item be affected by the 
location of the main class?  In my case, it isn't in the main jar. In 
fact, the main jar is empty except for the manifest, which contains 
only the manifest version declaration. The main class is located in 
one of the other jar files, which are correctly included in the 
resulting image and installer. The .cfg correctly includes those JARs 
on the classpath (and it all works fine when installed). I don't 
really see how that should affect the creation of a shortcut to the 
.exe, but thought I would mention it.


TIA!
Chris



On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick > wrote:


Strange ...

I can't seem to reproduce any scenario where msi installer created by
jpackage won't install a shortcut, but from the message:

"Multiple launchers found in predefined app-image. jvm will be
used as
primary launcher."

It seems that  you are using a predefined app-image  and there are
multiple launchers in the app-image, and the code is choosing
"jvm" as
the primary one (the one a shortcut will be created for).

This may be the wrong launcher.  When an installer is built for an
existing app-image, it doesn't know the name of the app, it looks for
the config file  in /app/

If there are multiple cfg files (like you built the app-image with
--add-launcher jvm=jvm-launcher.properties) it is just taking the
first one.

Is it possible this is what is happening in your case ?

/Andy

On 9/12/2019 9:54 AM, Christopher Merrill wrote:
> I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build
an MSI
> installer. If I am understanding the comments in thread "RFR:
JDK-8229779:
> Shortcut creation policy", a start menu entry (and desktop
shortcut?)
> should always be produced with this version of jpackage command line
> options? The MSI installer I've created does not create a start
menu entry,
> even when I include the --win-menu option. Other people seem to
have the
> opposite problem (start menu item when they don't want it), so
clearly I'm
> doing something wrong...
>
> C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output
> D:\Work\MuseProject\ide\closed\install\build\jpackage --name
> MuseIDE-launcher --app-image
>
D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher
> --win-per-user-install --win-menu --app-version 3.1 --name
MuseIDE-Launcher
>
> Other than this message, which I assume is a warning, the
execution is
> successful:
>    Multiple launchers found in predefined app-image. jvm will be
used as
> primary launcher.
>
> Are there other options that would influence getting a start
menu item
> added by the installer?
>
> FWIW, I am using gradle with the org.beryx.runtime plugin to

8229471: Calendar under a specific timezone changes HOUR field when MILLISECOND field is changed

[Yano, Masanori]

Hello.

I think JDK-8229471 occurs because a change of TimeZone is not considered in 
getTime().
To resolve this problem, isTimeSet flag must be set to false when setTimeZone() 
is called.

Please review the following change.

diff -r e1269de19aa5 src/java.base/share/classes/java/util/Calendar.java
--- a/src/java.base/share/classes/java/util/Calendar.java  Thu Aug 22 
14:09:36 2019 -0700
+++ b/src/java.base/share/classes/java/util/Calendar.java  Thu Sep 12 
11:45:37 2019 +0900
@@ -2901,7 +2901,7 @@
  * generally, a call to setTimeZone() affects calls to set() BEFORE AND
  * AFTER it up to the next call to complete().
  */
-areAllFieldsSet = areFieldsSet = false;
+isTimeSet = areAllFieldsSet = areFieldsSet = false;
 }

 /**
diff -r e1269de19aa5 test/jdk/java/util/Calendar/Bug8229471.java
--- /dev/null  Thu Jan 01 00:00:00 1970 +
+++ b/test/jdk/java/util/Calendar/Bug8229471.java  Thu Sep 12 11:45:37 2019 
+0900
@@ -0,0 +1,22 @@
+/*
+ *@test
+ *@bug 8229471
+ *@summary test for recompute when Calendar.setTimeZone()
+ */
+
+import java.util.Calendar;
+import java.util.Date;
+import java.util.Locale;
+import java.util.TimeZone;
+
+public class Bug8229471 {
+public static void main(String[] args) throws Exception {
+Calendar calendar = Calendar.getInstance(new Locale("en", "US"));
+Date date1 = calendar.getTime();
+calendar.setTimeZone(TimeZone.getTimeZone("Europe/Budapest"));
+Date date2 = calendar.getTime();
+if (date1.equals(date2)) {
+throw new RuntimeException("Bug8229471: failed. TimeZone is not 
applied.");
+}
+}
+}

Regards,
Masanori Yano

Re: RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit

[Sean Mullan]

This is in the security-libs area, not core-libs. Cross-posting to 
security-dev and bcc-ing core-libs-dev.


--Sean

On 9/12/19 6:40 AM, Thomas Stüfe wrote:

Hi all,

may I please have reviews for the following trivial build fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8230910
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/

Thanks,

Thomas

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

[Martin Buchholz]

On Thu, Sep 12, 2019 at 4:36 AM Pavel Rappo  wrote:

>
> I should have expressed myself more clear. I meant that the main thread
> and the thread created (and started) by `newStartedThread` (the test tread)
> do not wait for *each other* before they begin. This might be needed to
> make sure that they start at the same time (loosely speaking, of course).
> One might argue that the importance of this diminishes with the increase of
> the timeout that the main thread uses to wait for the test thread to die
> and the accuracy of measurements one agrees to tolerate.
>
>
You want coordination?  We got coordination.

Here's some infrastructure that uses a threadsStarted latch:

void assertThrowInterruptedExceptionWhenInterrupted(Action[] actions) {
int n = actions.length;
Future[] futures = new Future[n];
CountDownLatch threadsStarted = new CountDownLatch(n);
CountDownLatch done = new CountDownLatch(n);

for (int i = 0; i < n; i++) {
Action action = actions[i];
futures[i] = cachedThreadPool.submit(new CheckedRunnable() {
public void realRun() throws Throwable {
threadsStarted.countDown();
try {
action.run();
shouldThrow();
}
catch (InterruptedException success) {}
catch (Throwable fail) {
threadUnexpectedException(fail); }
assertFalse(Thread.interrupted());
done.countDown();
}});
}

await(threadsStarted);
assertEquals(n, done.getCount());
for (Future future : futures) // Interrupt all the tasks
future.cancel(true);
await(done);
}

When communicating a request, just like in real life, you can't force
others to do anything, so be politely Canadian and use "please" in the name
of your latch

/**
 * await throws InterruptedException if interrupted before counted down
 */
public void testAwait_Interruptible() {
final CountDownLatch l = new CountDownLatch(1);
final CountDownLatch pleaseInterrupt = new CountDownLatch(1);
Thread t = newStartedThread(new CheckedRunnable() {
public void realRun() throws InterruptedException {
Thread.currentThread().interrupt();
try {
l.await();
shouldThrow();
} catch (InterruptedException success) {}
assertFalse(Thread.interrupted());

pleaseInterrupt.countDown();
try {
l.await();
shouldThrow();
} catch (InterruptedException success) {}
assertFalse(Thread.interrupted());

assertEquals(1, l.getCount());
}});

await(pleaseInterrupt);
if (randomBoolean()) assertThreadBlocks(t, Thread.State.WAITING);
t.interrupt();
awaitTermination(t);
}

Re: Feedback JEP 343: jpackage --win-menu

[Christopher Merrill]

Thanks Andy.

Ok, so the image was created in the previous step using:
C:\Apps\OpenJDKs\jdk-14/bin/jpackage.exe --input
D:\Work\MuseProject\ide\closed\install\build\image\lib --main-jar
MuseIDE-launcher-3.1.jar --main-class org.musetest.ide.launcher.Bootstrap
--output D:\Work\MuseProject\ide\closed\install\build\jpackage --name
MuseIDE-launcher --identifier org.musetest.ide.launcher.Bootstrap
--runtime-image D:\Work\MuseProject\ide\closed\install\build\image

There is only one .cfg file in the .../build/image folder, 'jvm.cfg', which
contains:
-server KNOWN
-client IGNORE

However, the output folder (../build/jpackage/MuseIDE-launcher/app) of the
second jpackage step which I referenced in the previous message contains a
MuseIDE-launcher.cfg file with:
[Application]
app.name=MuseIDE-launcher
app.version=1.0
app.runtime=$APPDIR\runtime
app.identifier=org.musetest.ide.launcher.Bootstrap
app.classpath=$APPDIR\app\MuseIDE-launcher-3.1.jar;$APPDIR\app\dynamic-classloader-0.2.jar;$APPDIR\app\IdeLaunchUpdate-2.3.jar;$APPDIR\app\jrt-fs.jar;$APPDIR\app\update4j-1.2.2.jar
app.mainjar=$APPDIR\app\MuseIDE-launcher-3.1.jar
app.mainclass=org.musetest.ide.launcher.Bootstrap
[JavaOptions]
[ArgOptions]

I didn't create or supply that file...so I assume jpackage did.

Could it be the missing windows start menu item be affected by the location
of the main class?  In my case, it isn't in the main jar. In fact, the main
jar is empty except for the manifest, which contains only the manifest
version declaration. The main class is located in one of the other jar
files, which are correctly included in the resulting image and installer.
The .cfg correctly includes those JARs on the classpath (and it all works
fine when installed). I don't really see how that should affect the
creation of a shortcut to the .exe, but thought I would mention it.

TIA!
Chris



On Thu, Sep 12, 2019 at 10:34 AM Andy Herrick 
wrote:

> Strange ...
>
> I can't seem to reproduce any scenario where msi installer created by
> jpackage won't install a shortcut, but from the message:
>
> "Multiple launchers found in predefined app-image. jvm will be used as
> primary launcher."
>
> It seems that  you are using a predefined app-image  and there are
> multiple launchers in the app-image, and the code is choosing "jvm" as
> the primary one (the one a shortcut will be created for).
>
> This may be the wrong launcher.  When an installer is built for an
> existing app-image, it doesn't know the name of the app, it looks for
> the config file  in /app/
>
> If there are multiple cfg files (like you built the app-image with
> --add-launcher jvm=jvm-launcher.properties) it is just taking the first
> one.
>
> Is it possible this is what is happening in your case ?
>
> /Andy
>
> On 9/12/2019 9:54 AM, Christopher Merrill wrote:
> > I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI
> > installer. If I am understanding the comments in thread "RFR:
> JDK-8229779:
> > Shortcut creation policy", a start menu entry (and desktop shortcut?)
> > should always be produced with this version of jpackage command line
> > options? The MSI installer I've created does not create a start menu
> entry,
> > even when I include the --win-menu option. Other people seem to have the
> > opposite problem (start menu item when they don't want it), so clearly
> I'm
> > doing something wrong...
> >
> > C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output
> > D:\Work\MuseProject\ide\closed\install\build\jpackage --name
> > MuseIDE-launcher --app-image
> > D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher
> > --win-per-user-install --win-menu --app-version 3.1 --name
> MuseIDE-Launcher
> >
> > Other than this message, which I assume is a warning, the execution is
> > successful:
> >Multiple launchers found in predefined app-image. jvm will be used as
> > primary launcher.
> >
> > Are there other options that would influence getting a start menu item
> > added by the installer?
> >
> > FWIW, I am using gradle with the org.beryx.runtime plugin to create the
> > image and installer. Are there settings/options/stuff in the image that
> > would affect creation of the start menu item?
> >
> > TIA!
> > Chris
> >
>


-- 
¡ɹǝʌo ǝɯ lloɹ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

Re: RFR 8230829 : Matcher matches a surrogate pair that crosses border of the region

[naoto . sato]

Looks good to me, Ivan.

Naoto

On 9/10/19 9:13 PM, Ivan Gerasimov wrote:

Hello!

When the regex.Matcher matches a supplementary codepoint, it may 
inadvertently cross the border of the explicitly specified region 
without noticing.


Would you please help review a simple fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230829
WEBREV: http://cr.openjdk.java.net/~igerasim/8230829/00/webrev/

Thanks in advance!

Re: Feedback JEP 343: jpackage --win-menu

[Andy Herrick]

Strange ...

I can't seem to reproduce any scenario where msi installer created by 
jpackage won't install a shortcut, but from the message:


"Multiple launchers found in predefined app-image. jvm will be used as 
primary launcher."


It seems that  you are using a predefined app-image  and there are 
multiple launchers in the app-image, and the code is choosing "jvm" as 
the primary one (the one a shortcut will be created for).


This may be the wrong launcher.  When an installer is built for an 
existing app-image, it doesn't know the name of the app, it looks for 
the config file  in /app/


If there are multiple cfg files (like you built the app-image with 
--add-launcher jvm=jvm-launcher.properties) it is just taking the first one.


Is it possible this is what is happening in your case ?

/Andy

On 9/12/2019 9:54 AM, Christopher Merrill wrote:

I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI
installer. If I am understanding the comments in thread "RFR: JDK-8229779:
Shortcut creation policy", a start menu entry (and desktop shortcut?)
should always be produced with this version of jpackage command line
options? The MSI installer I've created does not create a start menu entry,
even when I include the --win-menu option. Other people seem to have the
opposite problem (start menu item when they don't want it), so clearly I'm
doing something wrong...

C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output
D:\Work\MuseProject\ide\closed\install\build\jpackage --name
MuseIDE-launcher --app-image
D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher
--win-per-user-install --win-menu --app-version 3.1 --name MuseIDE-Launcher

Other than this message, which I assume is a warning, the execution is
successful:
   Multiple launchers found in predefined app-image. jvm will be used as
primary launcher.

Are there other options that would influence getting a start menu item
added by the installer?

FWIW, I am using gradle with the org.beryx.runtime plugin to create the
image and installer. Are there settings/options/stuff in the image that
would affect creation of the start menu item?

TIA!
Chris

Re: RFR: jsr166 integration 2019-09

[Martin Buchholz]

On Thu, Sep 12, 2019 at 1:48 AM Remi Forax  wrote:

> This remember me something,
> we should refactor most of the the package-private final methods (and the
> corresponding constructors) at least inside java.lang/java.util to make
> them private, there is no need to make them package-private anymore given
> that since Java 11 the compiler emits nestmate attributes instead of
> generating the method access$XXX.
>
> Maybe i should write a bytecode analyzer for that ?
>

Right! Going the other way it was fairly easy to trawl through the
generated bytecode using javap looking for "access$".
I don't think the nestmates feature is really complete until there is an
easy tool to find all the package-private elements accessed only within
their nest.

Feedback JEP 343: jpackage --win-menu

[Christopher Merrill]

I am using build 14-jpackage+1-35 with WiX 3.11.1.2318 to build an MSI
installer. If I am understanding the comments in thread "RFR: JDK-8229779:
Shortcut creation policy", a start menu entry (and desktop shortcut?)
should always be produced with this version of jpackage command line
options? The MSI installer I've created does not create a start menu entry,
even when I include the --win-menu option. Other people seem to have the
opposite problem (start menu item when they don't want it), so clearly I'm
doing something wrong...

C:\Apps\OpenJDKs\jdk-14/bin/jpackage --package-type msi --output
D:\Work\MuseProject\ide\closed\install\build\jpackage --name
MuseIDE-launcher --app-image
D:\Work\MuseProject\ide\closed\install\build\jpackage/MuseIDE-launcher
--win-per-user-install --win-menu --app-version 3.1 --name MuseIDE-Launcher

Other than this message, which I assume is a warning, the execution is
successful:
  Multiple launchers found in predefined app-image. jvm will be used as
primary launcher.

Are there other options that would influence getting a start menu item
added by the installer?

FWIW, I am using gradle with the org.beryx.runtime plugin to create the
image and installer. Are there settings/options/stuff in the image that
would affect creation of the start menu item?

TIA!
Chris

-- 
¡ɹǝʌo ǝɯ lloɹ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

Re: RFR(s): 8228580: DnsClient TCP socket timeout

[Pavel Rappo]

I like the wording, it's concise. Thanks a lot for helping us with this, Chris!

Trivially, there's a typo: <2> instead of .

> On 12 Sep 2019, at 12:41, Chris Hegarty  wrote:
> 
> Here is an initial attempt to document these timeout/retry properties. It’s 
> effectively the wording lifted from the tech notes [1], with “UDP” removed.
> 
> I deliberately avoided describing the implementation. It serves little 
> purpose, and in fact will greatly complicate the description, as well as 
> constrain the implementation. I personally dislike parts of the existing 
> implementation ( which I will ignore ), so baking them into the spec would be 
> a mistake.
> 
> There are clearly a lot more properties that could be specified, that is far 
> far beyond the scope of this change.
> 
> If we add such documentation, then a CSR ( with JDK-scope ) will be needed.
> 
> --- a/src/jdk.naming.dns/share/classes/module-info.java
> +++ b/src/jdk.naming.dns/share/classes/module-info.java
> @@ -26,7 +26,38 @@
>  /**
>   * Provides the implementation of the DNS Java Naming provider.
>   *
> + * <2>Environment Properties
> + *
> + *  The following JNDI environment properties are relevant to the DNS
> + * provider.
> + *
> + * 
> + *com.sun.jndi.dns.timeout.initial
> + *com.sun.jndi.dns.timeout.retries
> + *  
> + *
> + *  These properties are used to alter the timeout-related defaults that 
> the
> + * DNS provider uses when submitting queries. The DNS provider submits 
> queries
> + * using the following exponential backoff algorithm. The provider submits a
> + * query to a DNS server and waits for a response to arrive within a timeout
> + * period (1 second by default). If it receives no response within the 
> timeout
> + * period, it queries the next server, and so on. If the provider receives no
> + * response from any server, it doubles the timeout period and repeats the
> + * process of submitting the query to each server, up to a maximum number of
> + * retries (4 by default).
> + *
> + *  The {@code com.sun.jndi.dns.timeout.initial} property, if set, 
> specifies
> + * the number of milliseconds to use as the initial timeout period (i.e., 
> before
> + * any doubling). If this property has not been set, the default initial 
> timeout
> + * is 1000 milliseconds.
> + *
> + *  The {@code com.sun.jndi.dns.timeout.retries} property, if set, 
> specifies
> + * the number of times to retry each server using the exponential backoff
> + * algorithm described previously. If this property has not been set, the
> + * default number of retries is 4.
> + *
>   * @provides javax.naming.spi.InitialContextFactory
> + *
>   * @moduleGraph
>   * @since 9
>   */
> 
> -Chris.
> 
> [1] https://docs.oracle.com/javase/6/docs/technotes/guides/jndi/jndi-dns.html
> 
>> On 11 Sep 2019, at 16:55, Alan Bateman  wrote:
>> 
>> On 11/09/2019 16:16, Pavel Rappo wrote:
>>> 
 On 11 Sep 2019, at 16:10, Alan Bateman  wrote:
 
 I assume extending the timeout to TCP will require at least some minimal 
 updates to the descriptions.
>>> Which descriptions do you have in mind? I cannot seem to find that text 
>>> anywhere in the current repo (jdk/jdk)
>> I don't think the jndi-dns docs page is in the jdk repo. Since JDK 9, a good 
>> place for service providers to document capability and configuration is 
>> their module description and I think at least some of the documentation from 
>> that page should move into the jdk.naming.dns module description (that's for 
>> another issue of course). However, for the changes under discussion here 
>> then I don't think it's unreasonable to provide an updated description of 
>> the timeout property.
>> 
>> -Alan
>> 
> 

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

[Rob McKenna]

This looks great to me. Thanks for taking a look at it.

-Rob

On 12/09/19 12:36, Pavel Rappo wrote:
> > On 12 Sep 2019, at 03:54, Martin Buchholz  wrote:
> > 
> > We're mostly in agreement.
> 
> Good to hear and I agree!
> 
> > On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo  > > wrote:
> > 
> >  
> > a. is not using any synchronization aid to make sure both threads wait for 
> > each other (probably, the timeout value accommodates that)
> > 
> > Thread.join is a synchronization aid!  But there's no shortage of others.  
> > We typically use a CountDownLatch to synchronize with another thread.
> 
> 
> I should have expressed myself more clear. I meant that the main thread and 
> the thread created (and started) by `newStartedThread` (the test tread) do 
> not wait for *each other* before they begin. This might be needed to make 
> sure that they start at the same time (loosely speaking, of course). One 
> might argue that the importance of this diminishes with the increase of the 
> timeout that the main thread uses to wait for the test thread to die and the 
> accuracy of measurements one agrees to tolerate.
> 
> I'm seeing differences in our timeout-measuring routines as just a difference 
> in tastes. Since a particular behavior here is not guaranteed anyway (as it's 
> not a hard real-time system), all we can hope for in both cases is adequate 
> timeout values and useful diagnostic output.
> 
> Thanks for patiently staying with this thread for so long, Martin.
> 
> 
>  ***
> 
> 
> Here's the updated version of the RFR based on the discussion so far:
> 
> http://cr.openjdk.java.net/~prappo/8151678/webrev.02/
> 
> For the reviewers. I totally forgot to explain why there's a multiplier of 2 
> in some of the timeout calculations. The reason is the current behavior of 
> InitialDirContext. The supplied connect timeout seems to be used twice. Once 
> for making the actual TCP connection [1] and the second time while waiting 
> for the server to respond to the BIND message [2]. Thus, the total time spent 
> in that InitialDirContext ctor may be twice the expected. I believe it's a 
> bug, but the bug that is not related to the issue in question. The current 
> issue (8151678) is about intermittent failures of LdapTimeoutTest.
> 
> -Pavel
> 
> ---
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296,
>  
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154,
>  
> http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365
> 

Re: RFR: JDK-8229779: Shortcut creation policy

[Alexey Semenyuk]

Looks good.

Would you mind creating a follow up CR to add jtreg test(s) for the new 
command line option.


- Alexey

On 9/12/2019 7:11 AM, Andy Herrick wrote:

Revised with webrev.03.

Changed SimplePackageTest instructions as suggested and added 
LinuxDebBundler.java to file list (double checked file list used to 
create webrev contains all changed files).


/ANdy

On 9/11/2019 10:09 PM, Alexey Semenyuk wrote:

SimplePackageTest.java:
I'd suggest to put "Installer should not create any shortcuts" in the 
description or simply remove notice about shortcuts.


Did you omit adding shortcuts to LinuxDebBundler.java on purpose?

- Alexey

On 9/11/2019 9:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

1.) adds the new option --linux-shortcut, and now only creates a 
shortcut on linux if specified


2.) only creates a shortcut on windows if win-menu or win-shortcut 
is specified.


/Andy


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

[2] http://cr.openjdk.java.net/~herrick/8229779

Re: RFR(s): 8228580: DnsClient TCP socket timeout

[Chris Hegarty]

Here is an initial attempt to document these timeout/retry properties. It’s 
effectively the wording lifted from the tech notes [1], with “UDP” removed.

I deliberately avoided describing the implementation. It serves little purpose, 
and in fact will greatly complicate the description, as well as constrain the 
implementation. I personally dislike parts of the existing implementation ( 
which I will ignore ), so baking them into the spec would be a mistake.

There are clearly a lot more properties that could be specified, that is far 
far beyond the scope of this change.

If we add such documentation, then a CSR ( with JDK-scope ) will be needed.

--- a/src/jdk.naming.dns/share/classes/module-info.java
+++ b/src/jdk.naming.dns/share/classes/module-info.java
@@ -26,7 +26,38 @@
 /**
  * Provides the implementation of the DNS Java Naming provider.
  *
+ * <2>Environment Properties
+ *
+ *  The following JNDI environment properties are relevant to the DNS
+ * provider.
+ *
+ * 
+ *com.sun.jndi.dns.timeout.initial
+ *com.sun.jndi.dns.timeout.retries
+ *  
+ *
+ *  These properties are used to alter the timeout-related defaults that the
+ * DNS provider uses when submitting queries. The DNS provider submits queries
+ * using the following exponential backoff algorithm. The provider submits a
+ * query to a DNS server and waits for a response to arrive within a timeout
+ * period (1 second by default). If it receives no response within the timeout
+ * period, it queries the next server, and so on. If the provider receives no
+ * response from any server, it doubles the timeout period and repeats the
+ * process of submitting the query to each server, up to a maximum number of
+ * retries (4 by default).
+ *
+ *  The {@code com.sun.jndi.dns.timeout.initial} property, if set, specifies
+ * the number of milliseconds to use as the initial timeout period (i.e., 
before
+ * any doubling). If this property has not been set, the default initial 
timeout
+ * is 1000 milliseconds.
+ *
+ *  The {@code com.sun.jndi.dns.timeout.retries} property, if set, specifies
+ * the number of times to retry each server using the exponential backoff
+ * algorithm described previously. If this property has not been set, the
+ * default number of retries is 4.
+ *
  * @provides javax.naming.spi.InitialContextFactory
+ *
  * @moduleGraph
  * @since 9
  */

-Chris.

[1] https://docs.oracle.com/javase/6/docs/technotes/guides/jndi/jndi-dns.html

> On 11 Sep 2019, at 16:55, Alan Bateman  wrote:
> 
> On 11/09/2019 16:16, Pavel Rappo wrote:
>> 
>>> On 11 Sep 2019, at 16:10, Alan Bateman  wrote:
>>> 
>>> I assume extending the timeout to TCP will require at least some minimal 
>>> updates to the descriptions.
>> Which descriptions do you have in mind? I cannot seem to find that text 
>> anywhere in the current repo (jdk/jdk)
> I don't think the jndi-dns docs page is in the jdk repo. Since JDK 9, a good 
> place for service providers to document capability and configuration is their 
> module description and I think at least some of the documentation from that 
> page should move into the jdk.naming.dns module description (that's for 
> another issue of course). However, for the changes under discussion here then 
> I don't think it's unreasonable to provide an updated description of the 
> timeout property.
> 
> -Alan
> 

Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

[Pavel Rappo]

> On 12 Sep 2019, at 03:54, Martin Buchholz  wrote:
> 
> We're mostly in agreement.

Good to hear and I agree!

> On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo  > wrote:
> 
>  
> a. is not using any synchronization aid to make sure both threads wait for 
> each other (probably, the timeout value accommodates that)
> 
> Thread.join is a synchronization aid!  But there's no shortage of others.  We 
> typically use a CountDownLatch to synchronize with another thread.


I should have expressed myself more clear. I meant that the main thread and the 
thread created (and started) by `newStartedThread` (the test tread) do not wait 
for *each other* before they begin. This might be needed to make sure that they 
start at the same time (loosely speaking, of course). One might argue that the 
importance of this diminishes with the increase of the timeout that the main 
thread uses to wait for the test thread to die and the accuracy of measurements 
one agrees to tolerate.

I'm seeing differences in our timeout-measuring routines as just a difference 
in tastes. Since a particular behavior here is not guaranteed anyway (as it's 
not a hard real-time system), all we can hope for in both cases is adequate 
timeout values and useful diagnostic output.

Thanks for patiently staying with this thread for so long, Martin.


 ***


Here's the updated version of the RFR based on the discussion so far:

http://cr.openjdk.java.net/~prappo/8151678/webrev.02/

For the reviewers. I totally forgot to explain why there's a multiplier of 2 in 
some of the timeout calculations. The reason is the current behavior of 
InitialDirContext. The supplied connect timeout seems to be used twice. Once 
for making the actual TCP connection [1] and the second time while waiting for 
the server to respond to the BIND message [2]. Thus, the total time spent in 
that InitialDirContext ctor may be twice the expected. I believe it's a bug, 
but the bug that is not related to the issue in question. The current issue 
(8151678) is about intermittent failures of LdapTimeoutTest.

-Pavel

---
[1] 
http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l296,
 
http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#l320
[2] 
http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l154,
 
http://hg.openjdk.java.net/jdk/jdk/file/79186d82463e/src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java#l365

Re: RFR: JDK-8230653: jpackage error on macOS system without xcode

[Andy Herrick]

looks good.

/Andy

On 9/11/2019 11:46 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Error mentioned in bug report was due to missing Xcode when running 
SetFile. Fixed by not running SetFile if Xcode is not available. This 
tool used to set custom icon on DMG file and we do not consider it as 
real error. Verbose output will indicate that custom icon is skipped 
for DMG.
- Signing will fail if Xcode is not installed. Added check for Xcode 
availability if signing is requested. If Xcode is not available and 
signing is specified we will fail with error.


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

[2] http://cr.openjdk.java.net/~almatvee/8230653/webrev.00

Thanks,
Alexander

Re: RFR: JDK-8229779: Shortcut creation policy

[Andy Herrick]

Revised with webrev.03.

Changed SimplePackageTest instructions as suggested and added 
LinuxDebBundler.java to file list (double checked file list used to 
create webrev contains all changed files).


/ANdy

On 9/11/2019 10:09 PM, Alexey Semenyuk wrote:

SimplePackageTest.java:
I'd suggest to put "Installer should not create any shortcuts" in the 
description or simply remove notice about shortcuts.


Did you omit adding shortcuts to LinuxDebBundler.java on purpose?

- Alexey

On 9/11/2019 9:07 PM, Andy Herrick wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


This fix:

1.) adds the new option --linux-shortcut, and now only creates a 
shortcut on linux if specified


2.) only creates a shortcut on windows if win-menu or win-shortcut is 
specified.


/Andy


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

[2] http://cr.openjdk.java.net/~herrick/8229779

Re: RFR: JDK-8230629: jpackage signing on macOS does not work as expected

[Alexey Semenyuk]

Looks good, though
---
List args = new ArrayList<>();
 940 args.addAll(Arrays.asList("codesign",
 941 "--verify",
 942 file.toString()));
 943
 944 ProcessBuilder pb
 945 = new ProcessBuilder(args.toArray(new 
String[args.size()]));

---

can be as simple as:
---
ProcessBuilder pb = new ProcessBuilder("codesign", "--verify", 
file.toString());

---

- Alexey

On 9/11/2019 11:53 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Binaries in runtime and Frameworks will not be signed directly using 
user provided certificate.
- libapplauncher.dylib will be signed with user provided certificate 
only if it is unsigned.
- When signing is enabled app and pkg will be signed, but not dmg. App 
inside pkg and dmg will be signed as well.


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

[2] http://cr.openjdk.java.net/~almatvee/8230629/webrev.00/

Thanks,
Alexander

Re: RFR: JDK-8230653: jpackage error on macOS system without xcode

[Alexey Semenyuk]

Looks good.

- Alexey

On 9/11/2019 11:46 PM, Alexander Matveev wrote:

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).


- Error mentioned in bug report was due to missing Xcode when running 
SetFile. Fixed by not running SetFile if Xcode is not available. This 
tool used to set custom icon on DMG file and we do not consider it as 
real error. Verbose output will indicate that custom icon is skipped 
for DMG.
- Signing will fail if Xcode is not installed. Added check for Xcode 
availability if signing is requested. If Xcode is not available and 
signing is specified we will fail with error.


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

[2] http://cr.openjdk.java.net/~almatvee/8230653/webrev.00

Thanks,
Alexander

RFR(T): 8230910: libsspi_bridge does not build on Windows 32bit

[Thomas Stüfe]

Hi all,

may I please have reviews for the following trivial build fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8230910
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8230910-libsspi_bridge_does_not_build_on_windows_32bit/webrev.00/webrev/

Thanks,

Thomas

Re: RFR: jsr166 integration 2019-09

[Remi Forax]

This remember me something,
we should refactor most of the the package-private final methods (and the 
corresponding constructors) at least inside java.lang/java.util to make them 
private, there is no need to make them package-private anymore given that since 
Java 11 the compiler emits nestmate attributes instead of generating the method 
access$XXX.

Maybe i should write a bytecode analyzer for that ?

Rémi

- Mail original -
> De: "Martin Buchholz" 
> À: "core-libs-dev" , "loom-dev" 
> , "David Holmes"
> 
> Envoyé: Lundi 9 Septembre 2019 17:06:28
> Objet: RFR: jsr166 integration 2019-09

> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
> 
> 8229442: AQS and lock classes refresh
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/lock-classes-refresh/index.html
> https://bugs.openjdk.java.net/browse/JDK-8229442
> 
> Lock classes refresh is a small step towards loom.
> Loom folk, how about adding Doug and I as Loom Project Committers, even
> though we have no concrete plans to submit to the loom repo yet?
> 
> Another round of stress testing at Google allowed us to fix a handful of
> very rare test failures.
> 
> 8227235: rare failures in testForkHelpQuiesce tck tests
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoin-quiesce/index.html
> https://bugs.openjdk.java.net/browse/JDK-8227235
> 
> 8221168: java/util/concurrent/CountDownLatch/Basic.java fails
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html
> https://bugs.openjdk.java.net/browse/JDK-8221168
> 
> 8145138: CyclicBarrier/Basic.java failed with "3 not equal to 4"
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CyclicBarrier-Basic/index.html
> https://bugs.openjdk.java.net/browse/JDK-8145138
> 
> 8225490: Miscellaneous changes imported from jsr166 CVS 2019-09
> https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellaneous/index.html
> https://bugs.openjdk.java.net/browse/JDK-8225490