Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

On Sep 26, 2016, at 12:01 PM, Michael Haupt wrote: > > thank you very much for your reviews - may I ask for a second round? > > The updated webrev is at > http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ >

Re: RFR(L): 8151179: address issues raised by JCK team on JEP 274 API

Hello, reviews, please ... ? Thanks, Michael > Am 26.09.2016 um 21:01 schrieb Michael Haupt : > > Hi John, all, > > thank you very much for your reviews - may I ask for a second round? > > The updated webrev is at > http://cr.openjdk.java.net/~mhaupt/8151179/webrev.01/ >

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Brent, Thank you for reviewing. Please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline below. On 2016/9/28 2:07, Brent Christian wrote: Thanks for making some improvements to these intermittent RMI tests. I agree with Roger that I don't thin

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Roger, Thank you for reviewing. Please check the new webrev: http://cr.openjdk.java.net/~mli/8085192/webrev.01/, and comments inline below. On 2016/9/27 23:14, Roger Riggs wrote: Hi Hamlin, Marking each test that uses RMID.launch with the bugid does not seem to be meaningful since the b

Review Request: JDK-8166238 Update jdeps for GNU-style long form options

Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8166238/webrev.00/index.html This patch renames the following options added in JDK 9 jdeps --gen-module-info => —generate-module-info -inverse => —-inverse -requires => —-require and also adds the long-form option co

Re: RFR: 8165944 jar utility doesn't process more than one -C argument

After a discussion with Paul Sandoz, I’ve simplified and, hopefully, thus clarified the changeset. The new webrev is http://cr.openjdk.java.net/~sdrach/8165944/webrev.01/ > On Sep 26, 2016, at 12:31 PM, Steve Drach wrote: > > Hi, > > P

[9] RFR: 8166645: Include locales plugin throws InternalError with "*" specified.

Hello, Please review the changes for the following issue: https://bugs.openjdk.java.net/browse/JDK-8166645 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8166645/webrev.00/ The fix makes sure that the supported language tags created by the plugin are in the original suppor

Re: RFR: JEP draft for Linux/s3990x port

On 9/27/16 10:49 AM, Volker Simonis wrote: Hi, can you please review and endorse the following draft JEP for the integration of the Linux/s390x port into the jkd9 master repository: https://bugs.openjdk.java.net/browse/JDK-8166730 Good. Add links to webrevs in a comment. It will help to get u

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Thanks for making some improvements to these intermittent RMI tests. I agree with Roger that I don't think we want to add the id to the @bug of every test. Also, it looks like there's an indentation change in JavaVM.java: 53 public static final long POLLTIME_MS = 100L; (I believe run

Re: RFR(M): 8166560: [s390] Basic enablement of s390 port.

On Fri, Sep 23, 2016 at 8:11 AM, David Holmes wrote: > Hi Goetz, > > I see a change not related directly to S390 ie change from ARM to ARM32 in > src/os/linux/vm/os_linux.cpp > The change looks a little confusing because Goetz reordered the ifdef cascades alphabetically (which I think is good).

Re: RFR(M): 8166560: [s390] Basic enablement of s390 port.

Hi Alan, I've created a JEP. You can find it here: https://bugs.openjdk.java.net/browse/JDK-8166730 I've also just sent an RFR for the JEP to the various list with some more detailed information. It would be great if you could review it for the class library. The changes to the jdk-repo are rea

RFR: JEP draft for Linux/s3990x port

Hi, can you please review and endorse the following draft JEP for the integration of the Linux/s390x port into the jkd9 master repository: https://bugs.openjdk.java.net/browse/JDK-8166730 As detailed in the JEP, the Linux/s390x requires very few shared changes and we therefore don't foresee any

RE: Proposal for adding O_DIRECT support into JDK 9

Alan, Thank you for the explanation, we will modify the code accordingly and send it out soon for review. Thanks, Lucy -Original Message- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Tuesday, September 27, 2016 8:45 AM To: Lu, Yingqi ; core-libs-dev@openjdk.java.net Cc: ni

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

> > I don't see any support in junit or testng for multi-threaded tests. TestNG has basic support on @Test for running a test method concurrently. This assumes synchronous code that does not perform complex coordination, e.g. simple writes into a ConcurrentMap. Specifically the annotation provide

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

If not a straight blocking method, a fluent conversion method to type R could be useful IMO: R to(Function, R> converter) { return converter.apply(this); } This way, who needs a blocking get can have a function prepared with a blocking operation: Function, T> blockingGet() { cs -> {

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

Thanks for pointing Mandy, this package naming does apply to xerces types. I am not aware of any xerces package inside JAX-WS components. I checked saaj-ri code and commented on issue (JDK-8166745). If elimination of com.sun.org.apache.xerces.internal.* is possible, it would not be an easy f

Re: Proposal for adding O_DIRECT support into JDK 9

On 26/09/2016 19:50, Lu, Yingqi wrote: Alan, you mean readv0/write0 or read0/write0? I just want to make sure :-) Apologies, I meant each of the native methods where the decision to use direct I/O or not would be a lot more maintainable in Java. You'll see that there are already code paths for

Re: [9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Hi Hamlin, Marking each test that uses RMID.launch with the bugid does not seem to be meaningful since the bug is in the support infrastructure of the test and not specific to the test itself. It would be overkill to try to confirm the bug was fixed by running all those tests. Putting the bug

Re: RFR(s): 8166624: java/util/jar/JarFile/mrjar regression tests has undeclared dependencies

Hi Alan, Looks like the root cause is jtreg issue. I'm going to close the CR as "Not an issue". Do you agree? Thank you for review. -- With best regards, Sergei 26.09.16 10:06, Alan Bateman wrote: On 25/09/2016 16:16, Sergei Kovalev wrote: If I've drop jdk.jartool, I faced with ClassNotFou

[9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Please review the fix for JDK-8085192. The fix checks whether it fails to launch rmid due to "Port already in use" error, it will launch rmid again and again(20 times at most) until no such issue. bug: https://bugs.openjdk.java.net/browse/JDK-8085192 webrev: http://cr.openjdk.java.net/~

Re: We need to add blocking methods to CompletionStage!

On Sep 27, 2016 01:18, "Martin Buchholz" wrote: > > > > On Mon, Sep 26, 2016 at 7:55 AM, Viktor Klang wrote: >>> >>> >>> >>> Test methods, >> >> >> Yeah, I thought so as well, but it turns out that when you have tons of async tests, not being able to start new tests until either that timeout or r

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

Seems legit -- Cheers, √ On Sep 26, 2016 23:29, "Attila Szegedi" wrote: > Not at all, you could just have a call to cancel() block until the future > completes. > > *ducks* > > Attila. > > > On 25 Sep 2016, at 16:34, Viktor Klang wrote: > > > > If that truely is the case then the only way of