RE: Which test groups to run instead of :jdk (8176838)

Hi Shura, thanks for your advice! So we'll run all of them. The number of additional tests is small enough to handle in case they fail. Do you mind if I put this advice into a comment in the bug? Best regards, Goetz. > -Original Message- > From: Alexandre (Shura) Iline

Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi Peter, I like what you have done here. That said the general thread-unsafeness of the code in SimpleTimeZone still causes me concern - but what you are doing is not breaking anything more than it is already broken. David On 25/11/2017 9:32 AM, Peter Levart wrote: Hi, @Venkat: Sorry for

RFR: jsr166 jdk10 integration wave 6

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html Thanks to Dávid Karnok and Pavel Rappo for help with SubmissionPublisher. 8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire methods throw 8187947: A race condition in SubmissionPublisher

RFR: jsr166 jdk10 integration wave 6

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html Thanks to Dávid Karnok and Pavel Rappo for help with SubmissionPublisher. 8191937: Lost interrupt in AbstractQueuedSynchronizer when tryAcquire methods throw 8187947: A race condition in SubmissionPublisher

Re: RFR 8187237: Need to define the behaviour for 0 and 1 argument method type in StringConcatFactory.makeConcat

On 11/27/17 6:08 PM, Paul Sandoz wrote: 8186737: Lookup argument for StringConcatFactory.makeConcat & makeConcatWithConstants cannot have privileges less than PRIVATE Please review these minor specification updates to the StringConcat bootstrap methods to clarify behaviour:

RFR: JDK-8186087: jar tool fails to create a multi-release jar when validating nested classes

Hi Please help review the change for #8186087 Issue: https://bugs.openjdk.java.net/browse/JDK-8186087 webrev: http://cr.openjdk.java.net/~sherman/8186087/webrev The proposed change is to handle the "outer class" of a nested class correctly, instead of simply relying on "top level" class.

RFR 8187237: Need to define the behaviour for 0 and 1 argument method type in StringConcatFactory.makeConcat

8186737: Lookup argument for StringConcatFactory.makeConcat & makeConcatWithConstants cannot have privileges less than PRIVATE Please review these minor specification updates to the StringConcat bootstrap methods to clarify behaviour:

Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API

This is a follow-up on JDK-8189611 that defines a new public API to return a stream of versioned entries and to return the real name of a JAR entry.  JDK-8189611 leaves jdeps untouched because jdeps is compiled with the boot JDK. This patch includes: (1) changes the build not to build

Re: RFR: JDK-8189611: JarFile versioned stream and real name support

Hi Sherman, My apology for the belated review.  I just return from vacation. On 11/20/17 6:58 PM, Xueming Shen wrote: http://cr.openjdk.java.net/~sherman/8189611/webrev Just passing comments. 140 * that {@link getName()} returns. should be #getName(). There are a couple other @link

Re: 8181175 Stream.concat behaves like terminal operation

> On 27 Nov 2017, at 14:38, Stuart Marks wrote: > > On 11/20/17 10:34 AM, Paul Sandoz wrote: >>> On 17 Nov 2017, at 17:18, Stuart Marks wrote: >>> The normative text about binding to the source and subsequent modifications >>> to the source

Re: 8181175 Stream.concat behaves like terminal operation

On 11/20/17 10:34 AM, Paul Sandoz wrote: On 17 Nov 2017, at 17:18, Stuart Marks wrote: The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense. I'm having trouble understanding

Re: Review Request: JDK-8190911: tools/jdeps/MultiReleaseJar.java failed with java.lang.IllegalThreadStateException

Looks good. Brian On Nov 27, 2017, at 2:02 PM, mandy chung wrote: > This is a simple test fix. The test fails because it calls > Process.exitValue() but the process hasn't exited. The test should wait for > the process to terminate or let it to timeout if something

Review Request: JDK-8190911: tools/jdeps/MultiReleaseJar.java failed with java.lang.IllegalThreadStateException

This is a simple test fix. The test fails because it calls Process.exitValue() but the process hasn't exited.  The test should wait for the process to terminate or let it to timeout if something goes wrong. Webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8190911/webrev.00/ Mandy

Re: Which test groups to run instead of :jdk (8176838)

Hi, Goetz. :jdk, when created, was supposed to include tests which could be run by full JDK, which is, well, all the tests. Over the time there could have been new tests added which were not included in the :jdk group. In fact, I have just now rolled the repository back to before the 8176838

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

This fixes my previous points, so fine by me. But I am not an OpenJDK reviewer. Stephen On 27 November 2017 at 20:54, Naoto Sato wrote: > Thanks, Stephen. Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/ > > Naoto

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Thanks, Stephen. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8176841.8189134.8190918.8191349/webrev.06/ Naoto On 11/23/17 8:13 AM, Stephen Colebourne wrote: In DateTimeFormatter line 1508, this would be preferred: return new DateTimeFormatter(printerParser, locale, ds,

Re: Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

On Nov 24, 2017, at 10:24 AM, Alan Bateman wrote: > If you backport JDK-8177809 and build with any recent gcc then you should > find that the results are consistent. If you really need to build gcc 4.1.x > (2006) then the changes for JDK-8177809 would require #ifdef

Re: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

I’d file an RFE to refactor the Deflater.c code. Following the zlib code is the right thing to do in order to stay consistent, even if it’s a bit rough. So, ship it. On 11/22/17, 9:43 AM, "Seán Coffey" wrote: On 22/11/2017 15:46, Hohensee, Paul wrote: >

Re: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

Thanks! I pushed it. Vladimir On 11/23/17 7:40 PM, Jaroslav Tulach wrote: 24. 11. 2017 v 2:33, mandy chung >: I'm okay with this fix. Just for the record: I am also fine with integrating my change. -jt On 11/21/17 3:26 PM, Vladimir

Re: RFR: 8189102: All tools should support -?, -h and --help

Hi, I looked at some of the components I maintain, and they look good. Wrt. the test: 1. The local variables/fields don't comply with the coding conventions, we have been following in the JDK. 2. Hmm, someone parked a .ini file in bin directory, later removed, perhaps on windows

Re: RFR: 8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

+1 On 11/22/17, 1:59 AM, Seán Coffey wrote: Looking to fix a recent regression that appeared in 8u151. Thanks goes to Sherman for the src patch. Paul Hohensee has also helped by provided some test code. I've been able to modify an existing test to mimic the behaviour seen with

Re: RFR: JDK8U Backport of 8154017: Shutdown hooks are racing against shutdown sequence, if System.exit()-calling thread is interrupted

Looks fine. Regards, Sean. On 27/11/17 08:17, Muneer Kolarkunnu wrote: Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017 JDK10 review thread:

Re: JDK-8191706: Proposal to add Reader::transferTo(Writer)

On 22/11/2017 18:36, Patrick Reinhart wrote: Webrev and CSR updated accordingly... -Patrick Spec and implementation looks good. -Alan

Re: RFR(s): 8191859: SoftReference clock/timestamp should be declared volatile

Hi Martin, On 2017-11-24 23:56, Martin Buchholz wrote: These fields have been this way for a very long time, probably intentionally non-volatile. Is there an observable problem being solved here? Sorry for not being more clear about that. Having them non-volatile can lead to the timestamp

RFR: JDK8U Backport of 8154017: Shutdown hooks are racing against shutdown sequence, if System.exit()-calling thread is interrupted

Hi All, Please review this webrev for jdk8u backport. Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/ Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017 JDK10 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041952.html JDK10 changeset: