Re: JDK 14 RFR of JDK-8229997: Apply java.io.Serial annotations in java.base

On 28/08/2019 02:28, Joe Darcy wrote: Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention of this new annotation type is to allow serialization-related fields and methods to be marke

AW: AW: jdk-14-jpackage+1-33 on jdk.java.net

Adding --win-console does indeed solve the problem. Thank you. Coming from JPackager (the version backported by GluonHQ to Java 11 - see [1]) - which does not have that option - I must have overlooked that in the help output of JPackage. -- Jonas [1] https://mail.openjdk.java.net/pipermail/op

RE: RFR (14) [testbug]: runs zero test, 8230002 and 8230010

Amy found them by grepping in all jtr log, she will setup a regular check since the issue raised from time to time. For this patch, then I will push it. Thanks Frank -Original Message- From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Wednesday, August 28, 2019 1:05 AM To: Frank Yua

JDK 14 RFR of JDK-8229997: Apply java.io.Serial annotations in java.base

Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention of this new annotation type is to allow serialization-related fields and methods to be marked as documentation and to allow strict

Re: RFR: JDK-8224833: jpackages differences between platforms

Looks good. Thanks, Alexander On 8/27/2019 4:25 PM, Alexey Semenyuk 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). [1] https://bugs.openjdk.java.net/browse/JDK-8224833 [2] http://cr.openjd

RFR: JDK-8224833: jpackages differences between platforms

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). [1] https://bugs.openjdk.java.net/browse/JDK-8224833 [2] http://cr.openjdk.java.net/~asemenyuk/8224833/webrev.00/ Thanks, Alexey

Re: RFR: JDK-8228660: .deb files generated by jpackage don't follow naming convention

Looks good. Thanks, Alexander On 8/27/2019 1:13 PM, Alexey Semenyuk 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). - fix implementation of --linux-app-release CLI option for Debian packagi

Re: RFR (S) 8226831 : Use Objects.equals() when appropriate

Thank you Roger and Brian! The fix has been pushed. With kind regards, Ivan On 8/27/19 1:12 PM, Brian Burkhalter wrote: Hi Ivan, +1 Brian On Aug 27, 2019, at 12:41 PM, Roger Riggs wrote: Hi Ivan, These look fine. Regards, Roger On 8/27/19 2:21 PM, Ivan Gerasimov wrote: Hello! nul

Re: RFR: JDK-8228660: .deb files generated by jpackage don't follow naming convention

Looks good to me, too. -- Kevin On 8/27/2019 1:29 PM, Andy Herrick wrote: looks good. /Andy On 8/27/2019 4:13 PM, Alexey Semenyuk 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). - fix imp

Re: RFR: JDK-8228660: .deb files generated by jpackage don't follow naming convention

looks good. /Andy On 8/27/2019 4:13 PM, Alexey Semenyuk 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). - fix implementation of --linux-app-release CLI option for Debian packaging; - use va

Re: RFR (S) 8226831 : Use Objects.equals() when appropriate

Hi Ivan, +1 Brian > On Aug 27, 2019, at 12:41 PM, Roger Riggs wrote: > > Hi Ivan, > > These look fine. > > Regards, Roger > > > On 8/27/19 2:21 PM, Ivan Gerasimov wrote: >> Hello! >> >> null-aware comparison of Objects is widely used, so it's tempting to use >> Objects.equals for that. >

RFR: JDK-8228660: .deb files generated by jpackage don't follow naming convention

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). - fix implementation of --linux-app-release CLI option for Debian packaging; - use value of --linux-app-release CLI option to construct Debian package

Re: RFR (S) 8226831 : Use Objects.equals() when appropriate

Hi Ivan, These look fine. Regards, Roger On 8/27/19 2:21 PM, Ivan Gerasimov wrote: Hello! null-aware comparison of Objects is widely used, so it's tempting to use Objects.equals for that. Unfortunately, there are concerns w.r.t performance (see JDK-8015417), so it seems to better avoid t

Re: [PATCH] JDK-8228580 DnsClient TCP socket timeout

Hi I agree that makes it more simple, but doing it this way ensures more precise timeout, subtracting the remaining time from global timeout value. I still rely on read() to throw SocketTimeoutException. The solution you suggest would potentially make each read() operation wait almost up to global

RFR (S) 8226831 : Use Objects.equals() when appropriate

Hello! null-aware comparison of Objects is widely used, so it's tempting to use Objects.equals for that. Unfortunately, there are concerns w.r.t performance (see JDK-8015417), so it seems to better avoid this kind of refactoring in the performance critical code. Please find the webrev with

8229333: java/io/File/SetLastModified.java timed out

The failure reported in [1] was observed to occur on two Mac minis with HDDs. Given the large file access it is possibly due to slow disk access. The suggested fix is to increase the timeout [2]. If it is still observed at a later date a new issue can be filed. Thanks, Brian [1] https://bugs.

RFR [14/java.xml] 8230094: CCE in createXMLEventWriter(Result) over an arbitrary XMLStreamWriter

Please review a patch for an issue where a custom impl of XMLStreamWriter caused a CCE. The problem was that our implementation was changed to an internally extended interface. We could consider making it external, but for now, we'll do with a check. Note that there's no material change in XML

Re: RFR (14) [testbug]: runs zero test, 8230002 and 8230010

Hi Frank, Thanks for fixing this. How did you find this out? Are you running some kind of tools? I hope that's the case since then we could be sure there were no other cases in the test suite. The patch looks good. It's fortunate we haven't broken anything ;-) The test passed just fine. Be

Re: WiX customization

The default WiX source file used by jpackage is [1]. WiX variables set by jpackage and referenced from this file have "Jp" prefix. The meaning of the variables is explained in doc comment of [2] file. It is also documented what WiX source files are generated by jpackage. So if you need to cust

Re: jdk-14-jpackage+1-33 on jdk.java.net

Unless you added the --win-console option, I think this is expected. Windows has a rather silly concept of console vs. window applications. To avoid a console window popping up when you don’t expected it, the default launcher is in ‘window’ mode, not ‘console’ mode. You need to know which kin

Re: RFR: JDK-8229871: Improve performance of Method.copy() and leafCopy()

Claes - do you have thoughts on this performance difference? Mandy On 8/26/19 11:41 PM, Kazunori Ogata wrote: Hi Mandy, Let me post interim results of the performance evaluation, though I'm still measuring benchmarks and analyzing them. For SPECjbb2015, skipping storing null (webrev.01) was f

Re: WiX customization

We are just beginning to work on user documentation, and --resource-dir is one area that will need extensive documentation and examples. (not to mention probably some bug fixes like JDK-8224833 ). basically the proceedure would be as follows:

Re: AW: jdk-14-jpackage+1-33 on jdk.java.net

to address this we added the option --win-console. I'm not sure why the comments in JDK-8211299 are marked as confidential (so you can't see them), but using --win-console option makes running the app more like running "java.exe" instead of "javaw.exe" (where stderr/stdout will not show). I

Re: RFR (14) [testbug]: runs zero test, 8230002 and 8230010

Hi Frank, Changes looks good to me. Thanks, Vyom On Tue, Aug 27, 2019 at 2:37 PM Frank Yuan wrote: > Hi all > > > > We found 2 jaxp tests, which didn't run indeed. > > > > Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8230002 > > Annotation @Test was missed in TestNG test. > > > > https:/

RFR (14) [testbug]: runs zero test, 8230002 and 8230010

Hi all We found 2 jaxp tests, which didn't run indeed. Bugs: https://bugs.openjdk.java.net/browse/JDK-8230002 Annotation @Test was missed in TestNG test. https://bugs.openjdk.java.net/browse/JDK-8230010 The old test was left during it was converted to TestNG test. Webrev: http:

AW: jdk-14-jpackage+1-33 on jdk.java.net

First of all: Thank you very much for JPackage. This looks very promising. To give some feedback: I just tried JPackage on Windows 10 and I believe I ran into this bug: https://bugs.openjdk.java.net/browse/JDK-8211299 It says the bug is fixed but I do not see anything written to either System.out