Sorry about the breakage. In retrospect, this is one jsr166 integration where we should have run more tests from other areas of the jdk. Especially monitoring tests are sensitive to implementation changes in j.u.c.locks. (but we've never run nsk tests)
On Sun, Sep 15, 2019 at 3:14 PM David Holmes <david.hol...@oracle.com> wrote: > Hi Martin, > > These changes have caused a number of tests to break and wreaked havoc > in our CI system (as those tests get executed a lot in different > configs). The problem seems to be changes to stack use and contents: > > - > > vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads* > - vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi* > - runtime/ReservedStack/ReservedStackTest.java > - java/lang/management/ThreadMXBean/LockedSynchronizers.java > > I'm filing bugs for each test group, but we may need to problem-list > them in the meantime. > > David > ----- > > On 14/09/2019 3:23 am, Martin Buchholz wrote: > > Thank you! > > > > On Fri, Sep 13, 2019 at 9:44 AM <fo...@univ-mlv.fr > > <mailto:fo...@univ-mlv.fr>> wrote: > > > > > > Android (d8 in fact) is able to desugar private access with > > nestmates since last April, > > your latest backport target 9 which is not supported anymore, so > > when you will move the backport to support Java 11, > > this tool can become handy. > > > > > > In fact, jsr166 CVS has already abandoned support for jdk9 (and jdk10) > > so there's absolutely no reason not to apply the suggestions made > > by Rémi's program. > > > > https://bugs.openjdk.java.net/browse/JDK-8230966 >
