Re: [EXTERNAL] JDK-8234076 bug fix candidate

2019-12-07 Thread Kumar Srinivasan
Hi, The launcher fix looks good, despite the launcher fix being simple, please note, it sometimes requires a lot more effort to write a test for it, please read on Henry excellent catch wrt. isTerminalOp the launcher!!!, that tickled my memory and I recalled this change for VM's native

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

2019-12-07 Thread Maurizio Cimadamore
Another update: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3/ And a delta of the changes since last version (v2) here: http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v3_delta/ The javadoc has been updated inline here:

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

2019-12-07 Thread David Holmes
Looks good! Thanks, David On 7/12/2019 11:34 pm, gerard ziemski wrote: Hi all, Please review this revision 2 of a cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself. The rev2 differs from rev1 in that it's

Re: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"

2019-12-07 Thread Phil Race
Ok. That makes sense. I was under the impression other tests were failing. So only the one update is needed for this and it is arguably just an omission. jpackage has a couple of types of requirement 1) run only on platforms that support jpackage - the @modiules will do this. 2) run only on a

Re: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"

2019-12-07 Thread Igor Ignatev
As far as I can see only junit.java test is executed on Solaris and is the only one failing. jtreg uses @modules during test selection/filtering phase, so tests which have @modules A won’t be run on jdk which doesn’t have module A, hence it should be sufficient. If it’s not, we have a bug in

Re: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"

2019-12-07 Thread Phil Race
All these tests specify this already so it doesn’t seem sufficient. -Phil. > On Dec 7, 2019, at 12:07 PM, Igor Ignatyev wrote: > > can we just add '@modules jdk.incubator.jpackage' to > test/jdk/tools/jpackage/junit/junit.java to solve that? or some of the tests > run by

Re: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"

2019-12-07 Thread Igor Ignatyev
can we just add '@modules jdk.incubator.jpackage' to test/jdk/tools/jpackage/junit/junit.java to solve that? or some of the tests run by test/jdk/tools/jpackage/junit/junit.java don't need jdk.incubator.jpackage module? -- Igor > On Dec 7, 2019, at 11:57 AM, Philip Race wrote: > > Yes,

Re: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"

2019-12-07 Thread Philip Race
Yes, since only a (relatively) small number of tests needed to be updated this is fine with me at least for now. So +1 -phil. On 12/7/19, 5:48 AM, Andy Herrick wrote: Phil - are you approving this change ? - I think you are the only registered Reviewer. /Andy On 12/6/2019 8:11 PM, Phil Race

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

2019-12-07 Thread Mandy Chung
Looks good. Mandy On 12/7/19 5:34 AM, gerard ziemski wrote: Hi all, Please review this revision 2 of a cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself. The rev2 differs from rev1 in that it's simpler due to

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

2019-12-07 Thread Maurizio Cimadamore
On 06/12/2019 21:04, Paul Sandoz wrote: GroupLayout.java — 80 OptionalLong sizeof(List elems) { 81 long size = 0; 82 for (MemoryLayout elem : elems) { 83 if (AbstractLayout.optSize(elem).isPresent()) { 84 size

RE: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

2019-12-07 Thread Langer, Christoph
Hi Gerard, this looks good. Cheers Christoph > -Original Message- > From: gerard ziemski > Sent: Samstag, 7. Dezember 2019 14:34 > To: hotspot-dev developers ; core-libs- > d...@openjdk.java.net; Claes Redestad ; > Mandy Chung ; David Holmes > ; Sergey Bylokhov > ; Langer, Christoph >

Re: RFR: JDK-8235453: tools/jpackage/junit/junit.java failed due to "module not found: jdk.incubator.jpackage"

2019-12-07 Thread Andy Herrick
Phil - are you approving this change ? - I think you are the only registered Reviewer. /Andy On 12/6/2019 8:11 PM, Phil Race wrote: Well we could deprecate and remove the solaris port :-) But until that is done this is the only way I know of. we could require all jpackage tests to include

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

2019-12-07 Thread Claes Redestad
Looks good to me! /Claes On 2019-12-07 14:34, gerard ziemski wrote: Hi all, Please review this revision 2 of a cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself. The rev2 differs from rev1 in that it's simpler

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

2019-12-07 Thread gerard ziemski
Hi all, Please review this revision 2 of a cleanup, where we remove JDK_GetVersionInfo0 and related code, since we can get build versions directly from within the VM itself. The rev2 differs from rev1 in that it's simpler due to JDK-8234185, which was just checked in yesterday. Waiting for

Re: JDK 14 RFR of JDK-8235514: Update record serialization tests to not use hard coded source versions

2019-12-07 Thread Chris Hegarty
Thanks for doing this Joe. The changes look good. -Chris. > On 6 Dec 2019, at 21:15, Joe Darcy wrote: > > Hello, > > Please review the patch below to update to the records serialization tests to > avoid hard-coded values for the -source argument during programmatic > invocations of the