Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

Here's a plan: Stuart commits his improvements, we then improve the code snippet in TimeUnit.timedWait, then change wait(long, int) api note to point at that. We can also add a "time-less" wait loop code snippet to the spec for nullary wait().

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

awaitUntil(Date) is weird in that it takes a wall clock Date that is subject to system administrator action like date(1). And Date is one of those classes everyone loves to hate. Usi

Re: """error: module testng reads package test from both test and testng"""

Indeed, when I rerun the command with your suggested module-path, it works (I had never used "rerun" before). So why does my jtreg not make these modules available at runtime? This is a fairly ordinary Ubuntu 14.4 system. $ DISPLAY=localhost:10.0 \ HOME=/home/martin \ LANG=en_US.UTF-8 \ PATH=/bi

Re: RFR 8173715: Remove Flat Profiler

Hi Gerard, On 23/08/2017 3:41 AM, Gerard Ziemski wrote: hi all, The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it’s the time to remove the code and obsolete the -Xprof flag. issue: https://bugs.openjdk.java.net/browse/JDK-8173715 webrev: http://cr.openjdk.java.net/~gziem

Re: """error: module testng reads package test from both test and testng"""

The error message is clear because testng is not found from the module path. Error occurred during initialization of boot layer java.lang.module.FindException: Module testng not found, required by test If you edit the rerun command from jtr file to add JTwork/modules to module path as follows:

Re: """error: module testng reads package test from both test and testng"""

I also tried upgrading jcommander.jar to 1.72 from 1.48, but get the same error. Debugging hints? On Tue, Aug 22, 2017 at 4:28 PM, mandy chung wrote: > > On 8/22/17 3:52 PM, Martin Buchholz wrote: > > : > > > ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] > REASON: User spec

Re: RFR JDK-8186464: ZipFile cannot read some InfoZip ZIP64 zip files

On 8/22/17, 5:54 PM, Martin Buchholz wrote: On Tue, Aug 22, 2017 at 3:27 PM, Xueming Shen > wrote: How about to add an option to our zipfs to force the ZIP64 end record when enabled. Harmless if not specified. I agree that adding more options for

Re: RFR JDK-8186464: ZipFile cannot read some InfoZip ZIP64 zip files

On Tue, Aug 22, 2017 at 3:27 PM, Xueming Shen wrote: > > How about to add an option to our zipfs to force the ZIP64 end record when > enabled. Harmless if not specified. > I agree that adding more options for testability is good. Since our users are likely to need such things as well, I'd also

Re: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

On 8/22/17 5:24 PM, Jonathan Gibbons wrote: It is also the hardest to review the diff.   A specdiff would help for this specification.  Skimming on the javadoc and seems okay. Specdiff has some amount of trouble, and so I don't entirely understand or trust what it was trying to show me.   Th

Re: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

On 08/22/2017 01:54 PM, mandy chung wrote: On 8/18/17 5:03 PM, Jonathan Gibbons wrote: Please review these fixes for various minor documentation issues in the java.base module. I reviewed the following files and the other files are already covered by Naoto and Martin. Here are more detail

Re: """error: module testng reads package test from both test and testng"""

On 8/22/17 3:52 PM, Martin Buchholz wrote: : ACTION: testng -- Failed. Unexpected exit from test [exit code: 1] REASON: User specified action: run testng/othervm test/test.Main TIME:   0.215 seconds messages: command: testng test/test.Main reason: User specified action: run testng/othervm test/

Re: """error: module testng reads package test from both test and testng"""

I tried updating my jtreg from testng 6.9.8 to 6.9.9 and got the insufficiently helpful Error occurred during initialization of boot layer java.lang.module.FindException: Module testng not found, required by test even though this new jtreg can run other testng tests successfully. Full log below:

Re: RFR JDK-8186464: ZipFile cannot read some InfoZip ZIP64 zip files

How about to add an option to our zipfs to force the ZIP64 end record when enabled. Harmless if not specified. Just try to avoid adding yet another shell test case ... http://cr.openjdk.java.net/~sherman/8186464/webrev On 08/22/2017 12:17 PM, Martin Buchholz wrote: On Mon, Aug 21, 2017 at 6

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

Webrev updated in place with reviews from Stas and Vladimir: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8185992-invoke-with-arguments-jumbo/webrev/ Paul. > On 18 Aug 2017, at 16:11, Paul Sandoz w

Re: """error: module testng reads package test from both test and testng"""

On 8/22/17 2:55 PM, Martin Buchholz wrote: On Tue, Aug 22, 2017 at 12:38 PM, mandy chung > wrote: Does your testng.jar contain classes of package "test"?   I downloaded testng from maven which does not have the package "test". Sorry, I missed that qu

Re: """error: module testng reads package test from both test and testng"""

On Tue, Aug 22, 2017 at 12:38 PM, mandy chung wrote: > Does your testng.jar contain classes of package "test"? I downloaded > testng from maven which does not have the package "test". > Sorry, I missed that question. Yes, for historical reasons we are using testng 6.9.8, and I see: $ ( wge

Re: """error: module testng reads package test from both test and testng"""

Mandy, thanks for the investigation. On Tue, Aug 22, 2017 at 12:38 PM, mandy chung wrote: > > The testng.jar version I had bundled with jcommander classes and hence the > error message reports com.beust.jcommander.* packages from jcommander and > testng module. It was an old version before test

Re: RFR: JDK-8186466: Fix accessibility and other minor issues in java.base

On 8/18/17 5:03 PM, Jonathan Gibbons wrote: Please review these fixes for various minor documentation issues in the java.base module. I reviewed the following files and the other files are already covered by Naoto and Martin. Here are more detailed notes on the changes: src/java.base/share/

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

On Aug 22, 2017, at 11:52 AM, Vladimir Ivanov wrote: > > I'm curious why there's a special case for Object[].class. > Also, should Object.class be used instead of Object[].class? You might be right. The optimization that we want is for an array of Object refs arguments.

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

> On 22 Aug 2017, at 09:52, Vladimir Ivanov > wrote: > > Overall, looks good. > > Some comments/questions: > > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java: > > +if (elemType == null) // must be array type > +return asFixedArity().invokeWith

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

> On 22 Aug 2017, at 02:58, stanislav lukyanov > wrote: > > Hi Paul, > > // a non-Reviewer here > Your review is still very welcome and valuable. > Some Javadoc nits: > > - package-info.Java > > optionally, between 1 and 251 additional static arguments taken from the > > constant pool >

Re: """error: module testng reads package test from both test and testng"""

Hi Martin, "error: module testng reads package test from both test and testng" indicates that a split package is detected.   Does your testng.jar contain classes of package "test"?   I downloaded testng from maven which does not have the package "test". The testng.jar version I had bundled w

Re: RFR JDK-8186464: ZipFile cannot read some InfoZip ZIP64 zip files

On Mon, Aug 21, 2017 at 6:35 PM, Xueming Shen wrote: > > I have manually verified the change does fix the problem (either use the > jar tf or > java jdk.nio.zipfs.ZipInfo to check the offending zip file). Given the > nature of the > test case, I'm hesitated to add this test as a unit/regression i

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

On 08/22/2017 07:10 PM, Claes Redestad wrote: > On 2017-08-22 18:34, Aleksey Shipilev wrote: >>> http://cr.openjdk.java.net/~redestad/8186500/jdk.01/ >> Still think testing for {null, Class, MethodHandle, MethodType} would cover >> more interesting corner >> cases. > > Do you mean as constant arg

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

It should be equivalent of having a String initialized with the result of String.valueOf() as constant argument. Rémi - Mail original - > De: "Claes Redestad" > À: "Aleksey Shipilev" , "Paul Sandoz" > > Cc: "core-libs-dev" > Envoyé: Mardi 22 Août 2017 19:10:29 > Objet: Re: RFR: 81865

RFR 8173715: Remove Flat Profiler

hi all, The FlatProfiler (i.e. -Xprof) has been deprecated in jdk9, and now it’s the time to remove the code and obsolete the -Xprof flag. issue: https://bugs.openjdk.java.net/browse/JDK-8173715 webrev: http://cr.openjdk.java.net/~gziemski/8173715_rev2_jdk/ cheers

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

On 2017-08-22 18:34, Aleksey Shipilev wrote: http://cr.openjdk.java.net/~redestad/8186500/jdk.01/ Still think testing for {null, Class, MethodHandle, MethodType} would cover more interesting corner cases. Do you mean as constant arguments? And what should happen in each of these cases? /

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

Overall, looks good. Some comments/questions: src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java: +if (elemType == null) // must be array type +return asFixedArity().invokeWithArguments(arguments); Since it's in AsVarargsCollector, is it possible th

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

On 08/22/2017 04:53 PM, Claes Redestad wrote: > Extending the existing StringConcatFactoryInvariants test we can easily get > most basic > combinations covered, along with some basic verification. > > This uncovered what appears to be a similar issue in the BC_SB SCF strategy, > which can be > d

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

On 8/22/17 6:19 AM, Jaroslav Tulach wrote: Thanks for your comments, Mandy. On pondělí 21. srpna 2017 12:42:09 CEST mandy chung wrote: cc'ing serviceability-dev which is the right mailing list for platform management discussion. JVMCI is currently named as `jdk.internal.vm.ci` (a JDK interna

Re: RFR: 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants

Extending the existing StringConcatFactoryInvariants test we can easily get most basic combinations covered, along with some basic verification. This uncovered what appears to be a similar issue in the BC_SB SCF strategy, which can be dealt with by coercing the possibly non-String constant to S

Re: RFR 8173817: StackOverflowError in "process reaper" thread

Hi, One option is to make code the function in a private method and use a method reference. But the code to generate the binding and the lambda mechanism would still look appear like magic. Thanks, Roger On 8/21/2017 9:42 PM, Martin Buchholz wrote: I suspect this won't save any stack frames

Re: [10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

Thanks for your comments, Mandy. On pondělí 21. srpna 2017 12:42:09 CEST mandy chung wrote: > cc'ing serviceability-dev which is the right mailing list for platform > management discussion. > > JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal > module). I suppose this new module

Re: [10] RFR 8186469 MethodHandle.invokeWithArguments jumbo-arity

Hi Paul, // a non-Reviewer here Some Javadoc nits: - package-info.Java > optionally, between 1 and 251 additional static arguments taken from the constant pool Looks like "between 1 and 251" part can be removed. It could also say "251 for non-varargs, unlimited for varargs" but it is already