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

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().toStri

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

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

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

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.

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

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 Pr

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

+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

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

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

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

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<>(

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

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 = ne

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

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  

Re: RFR: JDK-8229779: Shortcut creation policy

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 1

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

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, you

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

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 relevan

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

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 exp

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

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

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

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

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 sho

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

Hi Sean, In addition to Naoto's comments. The change to TimeZone_md.h should not be needed. A 'static' declaration doesn't need to be visible outside its source file. Roger On 9/12/19 12:42 PM, naoto.s...@oracle.com wrote: Hi Seán, I like your approach to provide the fast path to determine

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

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

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

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" vali

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

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 unrel

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

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 everythin

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

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

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

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:

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

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 t

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

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

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

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://bu

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

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

Re: RFR: jsr166 integration 2019-09

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 anymo

Feedback JEP 343: jpackage --win-menu

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 M

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

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

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

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 >

Re: RFR: JDK-8229779: Shortcut creation policy

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 checke

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

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

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

> 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 (

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

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. Fix

Re: RFR: JDK-8229779: Shortcut creation policy

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

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

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()]));

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

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.

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

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

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 a