RFR 8173159, Problem list java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java on Windows

2017-01-20 Thread Felix Yang
Hi there, please review the request to problem-list the test on Windows platform. It has been observed to be failing frequently. Bug https://bugs.openjdk.java.net/browse/JDK-8173159 Thanks, Felix diff -r 1045f9722697 test/ProblemList.txt

Re: RFR 8172732: spec clarification for URLClassLoader for Multirelease jars

2017-01-20 Thread Mandy Chung
+1 Mandy > On Jan 20, 2017, at 3:48 PM, Paul Sandoz wrote: > > Hi, > > Please review this small clarification to the specification of URLClassLoader > for multi-release jars. > > Thanks, > Paul. > > diff -r 467b3b7aeb1b src/java.base/share/classes/java/net/URLClassLoader.java > --- a/src/ja

RFR 8172732: spec clarification for URLClassLoader for Multirelease jars

2017-01-20 Thread Paul Sandoz
Hi, Please review this small clarification to the specification of URLClassLoader for multi-release jars. Thanks, Paul. diff -r 467b3b7aeb1b src/java.base/share/classes/java/net/URLClassLoader.java --- a/src/java.base/share/classes/java/net/URLClassLoader.java Fri Jan 20 07:05:40 2017 -0800 +

Re: Reading subprocess stdout susceptible to deadlock

2017-01-20 Thread Vitaly Davidovich
Hi all, Just wanted to revisit this issue again. I haven't filed a JBS entry for it, primarily because I'd like some validation/confirmation/hunch that this is, indeed, a bug before proceeding. Does anyone have thoughts on this scenario? Thanks On Wed, Mar 30, 2016 at 10:45 AM, Vitaly Davidovi

RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11

2017-01-20 Thread Xueming Shen
Hi, Please review the change to upgrade the zlib bundled in jdk repo from v1.2.8 to v1.2.11. jdk9 by default has been configured to build by using the native/ platform/os's zlib on all non-windows platform [1] So the change will only have effect on the Windows' binaries. issue: https://bugs.o

Re: RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom result in circularity issues

2017-01-20 Thread Paul Sandoz
> On 20 Jan 2017, at 09:54, Martin Buchholz wrote: > >>> > (r = (long) SEED.get(t)) + GAMMA); > => > r = ((long) SEED.get(t)) + GAMMA); > or I think you can just leave them out > r = (long) SEED.get(t) + GAMMA); > Doh, yes i see now, cross eyed! either of those two is fine. Thanks, Paul.

Re: RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom result in circularity issues

2017-01-20 Thread Martin Buchholz
> (r = (long) SEED.get(t)) + GAMMA); => r = ((long) SEED.get(t)) + GAMMA); or I think you can just leave them out r = (long) SEED.get(t) + GAMMA); On Fri, Jan 20, 2017 at 9:48 AM, Paul Sandoz wrote: > > On 20 Jan 2017, at 09:45, Martin Buchholz wrote: > > > > On Fri, Jan 20, 2017 at 7:58 AM,

Re: RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom result in circularity issues

2017-01-20 Thread Paul Sandoz
> On 20 Jan 2017, at 09:45, Martin Buchholz wrote: > > > > On Fri, Jan 20, 2017 at 7:58 AM, Paul Sandoz > wrote: > >> I was surprised to see below a change in parentheses that seems to change >> the behavior. >> >> final long nextSeed() { >> Thr

Re: RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom result in circularity issues

2017-01-20 Thread Martin Buchholz
On Fri, Jan 20, 2017 at 7:58 AM, Paul Sandoz wrote: > > I was surprised to see below a change in parentheses that seems to change > the behavior. > > final long nextSeed() { > Thread t; long r; // read and update per-thread seed > -SEED.set(t = Thread.currentThread(), > -

Re: Stream based API for tree like structures

2017-01-20 Thread Jonathan Bluett-Duncan
Hi Kasper, If what you're looking for is a more immediate solution, I can think of a couple of libraries which may do the trick: 1. Durian 's TreeDef and TreeStream. Difficult to understand and use at first, but I believe it ticks a good number of boxe

Re: RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom result in circularity issues

2017-01-20 Thread Paul Sandoz
> On 19 Jan 2017, at 19:23, Martin Buchholz wrote: > > Seems OK. Thanks. > It would be nice to somehow get more confidence we don't have remaining > circularities. From my experience usually these kind of circularities show up intermittently but regularly enough. Tricky to induce locally.

Re: 8172971: java.management could use System.Logger

2017-01-20 Thread Mandy Chung
> On Jan 20, 2017, at 5:07 AM, Daniel Fuchs wrote: > > The rest is unchanged (only test changes). > > http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.01/ > +1 Mandy

Re: RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor should not specify JDK-specific property

2017-01-20 Thread Seán Coffey
Roger, Lance, Thanks for the reviews. I'll make the suggested edit before pushing. Just waiting on CCC approval now. Regards, Sean. On 19/01/17 18:28, Roger Riggs wrote: Hi Sean, Looks ok but can you turn those texts into a sentence (capitalize it and final ".'). Thanks, Roger On 1/19/

Re: Stream based API for tree like structures

2017-01-20 Thread Remi Forax
https://gist.github.com/forax/bca6877e019d134f87c4cb1e8efae9cd Rémi - Mail original - > De: "Kasper Nielsen" > À: "core-libs-dev" > Envoyé: Vendredi 20 Janvier 2017 11:03:41 > Objet: Stream based API for tree like structures > Hi, > > Sorry if this is a bit off-topic, but I thought bu

Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

2017-01-20 Thread Alan Bateman
On 20/01/2017 13:21, Ramanand Patil wrote: Hi all, Please review the following bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8167063 Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/ Handled the SecurityException and LinkageError which can be thrown from Class.forName(...)

RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

2017-01-20 Thread Ramanand Patil
Hi all, Please review the following bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8167063 Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/ Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added

Re: 8172971: java.management could use System.Logger

2017-01-20 Thread Daniel Fuchs
Hi Mandy, On 19/01/17 19:07, Mandy Chung wrote: This test should have @modules java.logging and java.management. OK - I believed @modules java.management should already be in TEST.ROOT I will double check. If @modules is specified in a test, it will override the one in TEST.properties (I thin

Stream based API for tree like structures

2017-01-20 Thread Kasper Nielsen
Hi, Sorry if this is a bit off-topic, but I thought but I thought it might have some general interest if Java ever got some proper tree/graph collection classes. Has anyone developed a stream based API that allows for tree based travels. I'm mainly thinking about functionality for 1) Whether or

Re: JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

2017-01-20 Thread Xueming Shen
On 1/20/17, 12:28 AM, Xueming Shen wrote: - The lower three bits of Flags in both headers indicate which time- stamps are present in the LOCAL extra field: bit 0 if set, modification time is present bit 1

Re: JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

2017-01-20 Thread Xueming Shen
Can put in something together with the fix. Probably a variant of ZOS that remove those sanity check. -Sherman On 1/20/17, 12:40 AM, Alan Bateman wrote: BTW: Do we need to create some test infrastructure to allow tests create specially crafted zip files? With changes like this then the implem

Re: JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

2017-01-20 Thread Alan Bateman
BTW: Do we need to create some test infrastructure to allow tests create specially crafted zip files? With changes like this then the implementation tolerates truncated extended timestamps but we don't have anything in the tests to be confident that such changes will keep working. -Alan

Re: JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

2017-01-20 Thread Xueming Shen
On 1/19/17, 11:44 PM, Alan Bateman wrote: On 19/01/2017 23:35, Xueming Shen wrote: Thanks Claes! webrev has been updated accordingly http://cr.openjdk.java.net/~sherman/8173072/webrev The changes looks okay although I'd to understand more as to why tools might be generating the extra field