Re: specdiff Re: RFR: jsr166 openjdk9 integration

I noticed that the Navigable* class descriptions were incompletely @link-ified. Index: src/main/java/util/NavigableMap.java === RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/NavigableMap.java,v retrieving revision 1.2

Re: specdiff Re: RFR: jsr166 openjdk9 integration

Note that the patches are not all independent - each patch was tested with previous patches applied. My original intent was to push all the patches at once, but of course there are testing advantages to pushing them individually. On Wed, Sep 30, 2015 at 5:59 AM, Paul Sandoz wrote: > > > On 30 S

Re: specdiff Re: RFR: jsr166 openjdk9 integration

> On 30 Sep 2015, at 04:16, Martin Buchholz wrote: > > Thanks for the specdiff - much easier to review for javadoc changes!. I went > through it. There were a small number of minor mistakes, which are now > corrected. Now would be a good time to regenerate the specdiff. > Updated. As you

Re: specdiff Re: RFR: jsr166 openjdk9 integration

Thanks for the specdiff - much easier to review for javadoc changes!. I went through it. There were a small number of minor mistakes, which are now corrected. Now would be a good time to regenerate the specdiff. On Thu, Sep 24, 2015 at 1:35 AM, Paul Sandoz wrote: > > > http://cr.openjdk.java.

Re: RFR: jsr166 openjdk9 integration

I added MOAT.java to the integration. We noticed very rare failures testing WeakHashMap if the GC intervened at just the wrong time. (There's also changes to make the test portable to jdk8, since we still test against that) http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integrati

Re: RFR: jsr166 openjdk9 integration

On 24 Sep 2015, at 19:57, Martin Buchholz wrote: > FlakyThreadFactory fixed: Thanks, verified. Paul. > (It would be nice if hotspot was consistent about the way it failed, > regardless of platform) > "Write once, fail anywhere" > > Index: > src/test/jtreg/util/concurrent/ThreadPoolExecutor/F

Re: RFR: jsr166 openjdk9 integration

On 24 Sep 2015, at 23:47, Martin Buchholz wrote: > I changed my export script to also publish my mercurial queues patches > directory. > Find it at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/patches/ Thanks, most helpful, Paul.

Re: RFR: jsr166 openjdk9 integration

I changed my export script to also publish my mercurial queues patches directory. Find it at http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/patches/

Re: RFR: jsr166 openjdk9 integration

FlakyThreadFactory fixed: (It would be nice if hotspot was consistent about the way it failed, regardless of platform) "Write once, fail anywhere" Index: src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java === RC

Re: RFR: jsr166 openjdk9 integration

On 24 Sep 2015, at 00:22, Martin Buchholz wrote: > > On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz wrote: > On 23 Sep 2015, at 21:33, Martin Buchholz wrote: >> >> >> In Helpers: >> >> 121 private static String newStringUnsafe(char[] chars) { >> 122 // If porting to a JDK where s

Re: RFR: jsr166 openjdk9 integration

I ran the patches through JPRT. I am noticing one test failure that i cannot reproduce locally but reproduces on some test machines. java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1335) at FlakyThreadFactory.fail(FlakyThreadFactory.java:93) at

specdiff Re: RFR: jsr166 openjdk9 integration

On 23 Sep 2015, at 23:41, Paul Sandoz wrote: >> If you generate a public specdiff (as I believe only Oracle folks can), it >> would be easier for all of us to review the spec changes. >> > > Yes, Roger also suggested the same to me off list. May happen tomorrow. > http://cr.openjdk.java.ne

Re: RFR: jsr166 openjdk9 integration

On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz wrote: > On 23 Sep 2015, at 21:33, Martin Buchholz wrote: > > >> >> In Helpers: >> >> 121 private static String newStringUnsafe(char[] chars) { >> 122 // If porting to a JDK where sun.misc.SharedSecrets is not >> 123 // availabl

Re: RFR: jsr166 openjdk9 integration

On Wed, Sep 23, 2015 at 1:05 PM, Chris Hegarty wrote: > > Right. jsr166 bulk updates generally contain so many diverse changes that I > always just assume a CCC would be required (in the past, this was done via > a single request instead of split up as we are doing here). > > > For 8 we separated

Re: RFR: jsr166 openjdk9 integration

On 23 Sep 2015, at 21:33, Martin Buchholz wrote: > > > On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz wrote: > Hi, > > I trawled through the patches and could not find anything obvious that > clobbered existing JDK stuff. > > In the misc/locks patches there are some classes that might contain

Re: RFR: jsr166 openjdk9 integration

> On 23 Sep 2015, at 20:33, Martin Buchholz wrote: > > On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz > wrote: > >> Hi, >> >> I trawled through the patches and could not find anything obvious that >> clobbered existing JDK stuff. >> >> In the misc/locks patches t

Re: RFR: jsr166 openjdk9 integration

On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz wrote: > Hi, > > I trawled through the patches and could not find anything obvious that > clobbered existing JDK stuff. > > In the misc/locks patches there are some classes that might contain spec > changes: > > ConcurrentLinkedDeque > CopyOnWriteA

Re: RFR: jsr166 openjdk9 integration

Hi, I trawled through the patches and could not find anything obvious that clobbered existing JDK stuff. In the misc/locks patches there are some classes that might contain spec changes: ConcurrentLinkedDeque CopyOnWriteArraySet ScheduledExecutorService ScheduledThreadPoolExecutor L

Re: RFR: jsr166 openjdk9 integration

The latest set of webrevs and bug reports has no known problems. I tried to find all the "bug dups" that were awaiting this integration. On Mon, Sep 21, 2015 at 12:21 PM, Paul Sandoz wrote: > Hi Martin, > > Thanks so much for doing this. > > Chris and I will cherry pick the appropriate API chang

Re: RFR: jsr166 openjdk9 integration

Hi Martin, Thanks so much for doing this. Chris and I will cherry pick the appropriate API changes required for CCC, which i believe only apply to the first three sub-tasks of JDK-8132960 (Flow, CompletableFuture, and ForkJoin), but we should need to double check. We also need to be careful we

RFR: jsr166 openjdk9 integration

This is the long-delayed and long-awaited bulk integration for jdk9 from jsr166 CVS. Find webrevs here: http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ Sorry about the extreme size and tardiness of this integration. As a review convenience, I provided a diff-wbB file