From martijnverburg at gmail.com  Tue Dec  6 09:22:08 2016
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 6 Dec 2016 09:22:08 +0000
Subject: JDK-6253001 - Joinrowset bug - question on whether test code has been
	migrated?
Message-ID: <CAP7YuASEjHMaa2HKkzvO1sY-2CRz=f4R4TEthBrFWOujDdKoBQ@mail.gmail.com>

Hi all,

The Adoption Group is having a go at collaboratively walking through the
process of resolving an open bug with the view of writing up the steps for
folks new to OpenJDK.

We picked https://bugs.openjdk.java.net/browse/JDK-6253001 - a fairly
simple, low priority joinrowset bug reported in the sql area.  Our
intention is to investigate the bug, reproduce it and *if* a fix is
required wait until the jdk 10 forests open to submit it there (as it's
only a P4).

-----

Of course with older bugs there is a hidden history :-).  The original test
is listed as living in:

com.sun.rowset.tests.smoke.joinrowset.joinrowset3.JoinRowSet3.testJoinRowSet22

However we're unable to find that exact test which means that either:

1.) It's an internal Sun/Oracle test
2.) It's been migrated / replaced by one of the tests in
*jdk/javax/sql/testing/test/rowset/joinrowset/JoinRowSetTests.java*

Does anyone familiar with the tests around the SQL package know the history
here?

Cheers,
Martijn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161206/d74db057/attachment.html>

From martijnverburg at gmail.com  Tue Dec  6 14:32:50 2016
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 6 Dec 2016 14:32:50 +0000
Subject: JDK-6253001 - Joinrowset bug - question on whether test code has
	been migrated?
In-Reply-To: <5E2872A6-B5EB-4B04-BB34-07FD843D9089@oracle.com>
References: <CAP7YuASEjHMaa2HKkzvO1sY-2CRz=f4R4TEthBrFWOujDdKoBQ@mail.gmail.com>
	<5E2872A6-B5EB-4B04-BB34-07FD843D9089@oracle.com>
Message-ID: <CAP7YuASew6UYM5A9_iSeG2ttE1Q87C--58RmJ01c5EwFJK431Q@mail.gmail.com>

Hi Lance,

Thanks!  We'll see if we can reproduce and if not then recommend that the
issue is closed as already fixed.

Cheers,
Martijn

On 6 December 2016 at 11:56, Lance Andersen <lance.andersen at oracle.com>
wrote:

> Hi Martjin,
>
>
> On Dec 6, 2016, at 4:22 AM, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
> Hi all,
>
> The Adoption Group is having a go at collaboratively walking through the
> process of resolving an open bug with the view of writing up the steps for
> folks new to OpenJDK.
>
> We picked https://bugs.openjdk.java.net/browse/JDK-6253001 - a fairly
> simple, low priority joinrowset bug reported in the sql area.  Our
> intention is to investigate the bug, reproduce it and *if* a fix is
> required wait until the jdk 10 forests open to submit it there (as it's
> only a P4).
>
> -----
>
> Of course with older bugs there is a hidden history :-).  The original test
> is listed as living in:
>
> com.sun.rowset.tests.smoke.joinrowset.joinrowset3.
> JoinRowSet3.testJoinRowSet22
>
> However we're unable to find that exact test which means that either:
>
> 1.) It's an internal Sun/Oracle test
>
> The test referenced in the bug is a test in an internal test suite which
> has since been retired.
>
> 2.) It's been migrated / replaced by one of the tests in
> *jdk/javax/sql/testing/test/rowset/joinrowset/JoinRowSetTests.java*
>
> That is correct
>
>
> Does anyone familiar with the tests around the SQL package know the history
> here?
>
>
> Best
> Lance
>
>
> Cheers,
> Martijn
>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037 <+1%20781-442-2037>
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161206/c9d0506a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161206/c9d0506a/oracle_sig_logo.gif>

From martinrb at google.com  Wed Dec 14 19:22:33 2016
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 14 Dec 2016 11:22:33 -0800
Subject: Repository? -- How many lines of development?
In-Reply-To: <583CD0D8.3000105@oracle.com>
References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com>
	<11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com>
	<32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com>
	<583CAABF.6000102@oracle.com>
	<CA+kOe0_6WaKaAkCYMpD6KwOp2XHGYF7_hYy2xeEa9OoGE5LEag@mail.gmail.com>
	<583CD0D8.3000105@oracle.com>
Message-ID: <CA+kOe0_qsH0LDjskhHm6mrUnr095J4-Pf+a76HHpZ6aCqaoQCQ@mail.gmail.com>

On Mon, Nov 28, 2016 at 4:50 PM, Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> On 11/28/2016 3:30 PM, Martin Buchholz wrote:
>
> As an aside, for JDK 10 I'd also like to see promoted builds on a more
>> frequent schedule than once a week.
>>
>
> People do "continuous testing and integration" these days.  Set up your
> integration pipeline so that it is always running.  The pipeline
> automatically promotes changesets to master when all tests pass.  Easy!
> Then every master changeset is equally stable to a "promoted build".
>
>
> One of the internal systems mentioned above is a CI system that run
> regression tests after a change is pushed. The approximate integration
> model is then to promote known-good states of sources as vetted by the CI
> system.
>
> If problems are fixed soon after they are identified, then a post-push
> system gives good results with avoiding the need more complexity on the
> front end to manage a series of in-flight patches.
>

A CI system available to every committer that would guarantee no
regressions would be awesome!

I fundamentally do not believe in post-submit testing. I want to be
protected from my own mistakes and those of others.  Google has also moved
towards doing more presubmit testing.

For large low-level infrastructure projects like openjdk, I envision
different layers of testing.  The first layer would run e.g. the jtreg and
jck tests, perhaps on a distributed test farm.  A second layer might run
publicly available java test suites that would be too expensive to run in a
first layer.  Promotion to a "golden master" might be dependent on passing
tests in the second layer.  Of course, that would be a serious investment
in testing/quality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161214/7f4f8f4c/attachment.html>

From joe.darcy at oracle.com  Thu Dec 15 01:05:52 2016
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 14 Dec 2016 17:05:52 -0800
Subject: Repository? -- How many lines of development?
In-Reply-To: <CA+kOe0_qsH0LDjskhHm6mrUnr095J4-Pf+a76HHpZ6aCqaoQCQ@mail.gmail.com>
References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com>
	<11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com>
	<32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com>
	<583CAABF.6000102@oracle.com>
	<CA+kOe0_6WaKaAkCYMpD6KwOp2XHGYF7_hYy2xeEa9OoGE5LEag@mail.gmail.com>
	<583CD0D8.3000105@oracle.com>
	<CA+kOe0_qsH0LDjskhHm6mrUnr095J4-Pf+a76HHpZ6aCqaoQCQ@mail.gmail.com>
Message-ID: <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com>

On 12/14/2016 11:22 AM, Martin Buchholz wrote:
>
>
> On Mon, Nov 28, 2016 at 4:50 PM, Joseph D. Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>     On 11/28/2016 3:30 PM, Martin Buchholz wrote:
>>
>>         As an aside, for JDK 10 I'd also like to see promoted builds
>>         on a more frequent schedule than once a week.
>>
>>
>>     People do "continuous testing and integration" these days.  Set
>>     up your integration pipeline so that it is always running.  The
>>     pipeline automatically promotes changesets to master when all
>>     tests pass.  Easy!  Then every master changeset is equally stable
>>     to a "promoted build".
>
>     One of the internal systems mentioned above is a CI system that
>     run regression tests after a change is pushed. The approximate
>     integration model is then to promote known-good states of sources
>     as vetted by the CI system.
>
>     If problems are fixed soon after they are identified, then a
>     post-push system gives good results with avoiding the need more
>     complexity on the front end to manage a series of in-flight patches.
>
>
> A CI system available to every committer that would guarantee no 
> regressions would be awesome!
>
> I fundamentally do not believe in post-submit testing. I want to be 
> protected from my own mistakes and those of others.  Google has also 
> moved towards doing more presubmit testing.
>
> For large low-level infrastructure projects like openjdk, I envision 
> different layers of testing.  The first layer would run e.g. the jtreg 
> and jck tests, perhaps on a distributed test farm.  A second layer 
> might run publicly available java test suites that would be too 
> expensive to run in a first layer.  Promotion to a "golden master" 
> might be dependent on passing tests in the second layer.  Of course, 
> that would be a serious investment in testing/quality.

The tiered testing efforts made earlier in JDK 9 [1] are necessary 
preconditions for a JDK-wide pre-push/pre-submit system. In particular, 
if you don't have a a set of meaningful tests that runs quickly enough 
and passes reliably enough then a pre-push system can cause more harm 
than good in introducing bottlenecks and causing changes to be 
spuriously rejected, say by an existing intermittent failure unrelated 
to the change.

If the testing preconditions are met, there is still the small matter of 
the submission system managing the queues, perhaps some with kind of 
scoreboarding algorithm (https://en.wikipedia.org/wiki/Scoreboarding) to 
reduce latencies, etc.

In the meantime, I think post-push testing and prompt fixing is a fine 
approximation to pre-push testing and something we can (continue to) do now.

Independent of pre-push or post-push, the most important aspect of this 
is making sure everyone treats build and test failures as urgent 
problems that need to be addressed quickly.

Cheers,

-Joe

[1] "Proposed new policies for JDK 9 regression tests: tiered testing, 
intermittent failures, and randomness,"
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html

?Proposed new policies for JDK 9 regression tests: tiered testing, 
intermittent failures, and randomness,?
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002164.html

?Test policy follow-up, third testing tier,?
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161214/8006637d/attachment-0001.html>

From martinrb at google.com  Thu Dec 15 04:25:43 2016
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 14 Dec 2016 20:25:43 -0800
Subject: Repository? -- How many lines of development?
In-Reply-To: <0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com>
References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com>
	<11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com>
	<32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com>
	<583CAABF.6000102@oracle.com>
	<CA+kOe0_6WaKaAkCYMpD6KwOp2XHGYF7_hYy2xeEa9OoGE5LEag@mail.gmail.com>
	<583CD0D8.3000105@oracle.com>
	<CA+kOe0_qsH0LDjskhHm6mrUnr095J4-Pf+a76HHpZ6aCqaoQCQ@mail.gmail.com>
	<0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com>
Message-ID: <CA+kOe0_kN8pUKJ_NuWqCcLmLZanvS8oNorEofn+1XNd-yyEXWw@mail.gmail.com>

On Wed, Dec 14, 2016 at 5:05 PM, joe darcy <joe.darcy at oracle.com> wrote:

>
> The tiered testing efforts made earlier in JDK 9 [1] are necessary
> preconditions for a JDK-wide pre-push/pre-submit system. In particular, if
> you don't have a a set of meaningful tests that runs quickly enough and
> passes reliably enough then a pre-push system can cause more harm than good
> in introducing bottlenecks and causing changes to be spuriously rejected,
> say by an existing intermittent failure unrelated to the change.
>

It's a hard problem, but I think with sufficient effort presubmit can work
well.  Testing is embarrassingly parallel in principle so with enough
hardware (or one of those "clouds" everyone is selling these days) one
should be able to run arbitrarily many tests.  No one seems to deal well
with flaky tests, but flakiness can be measured, and a failing test can be
rerun arbitrarily, so deflaking should be automatable.

At Google we are starting to experiment with running jtreg tests with
massive parallelism.

Automation, presubmit testing and never-ever-broken master remain my goals
for any software project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161214/3785982f/attachment.html>

From weijun.wang at oracle.com  Thu Dec 15 04:32:59 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 15 Dec 2016 12:32:59 +0800
Subject: Repository? -- How many lines of development?
In-Reply-To: <CA+kOe0_kN8pUKJ_NuWqCcLmLZanvS8oNorEofn+1XNd-yyEXWw@mail.gmail.com>
References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com>
	<11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com>
	<32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com>
	<583CAABF.6000102@oracle.com>
	<CA+kOe0_6WaKaAkCYMpD6KwOp2XHGYF7_hYy2xeEa9OoGE5LEag@mail.gmail.com>
	<583CD0D8.3000105@oracle.com>
	<CA+kOe0_qsH0LDjskhHm6mrUnr095J4-Pf+a76HHpZ6aCqaoQCQ@mail.gmail.com>
	<0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com>
	<CA+kOe0_kN8pUKJ_NuWqCcLmLZanvS8oNorEofn+1XNd-yyEXWw@mail.gmail.com>
Message-ID: <CA112859-951F-4783-93B6-A6598EA9C71C@oracle.com>

IMHO never-ever-broken master is the main obstacle here, the auto-rerun feature you suggested is nice, but I am also in favor of a could-fail-do-not-panic keyword.

--Max

> On Dec 15, 2016, at 12:25 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Automation, presubmit testing and never-ever-broken master remain my goals
> for any software project.


From martijnverburg at gmail.com  Thu Dec 15 09:10:12 2016
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 15 Dec 2016 09:10:12 +0000
Subject: Repository? -- How many lines of development?
In-Reply-To: <0b3d06485bc4458c829d22982fa59d02@DEROTE13DE08.global.corp.sap>
References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com>
	<11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com>
	<32589a52-5e9f-dc65-3c99-bd5f9c475b06@oracle.com>
	<583CAABF.6000102@oracle.com>
	<CA+kOe0_6WaKaAkCYMpD6KwOp2XHGYF7_hYy2xeEa9OoGE5LEag@mail.gmail.com>
	<583CD0D8.3000105@oracle.com>
	<CA+kOe0_qsH0LDjskhHm6mrUnr095J4-Pf+a76HHpZ6aCqaoQCQ@mail.gmail.com>
	<0ccd3d0e-5ea2-6409-ae9d-7f15ef6b8c22@oracle.com>
	<CA+kOe0_kN8pUKJ_NuWqCcLmLZanvS8oNorEofn+1XNd-yyEXWw@mail.gmail.com>
	<0b3d06485bc4458c829d22982fa59d02@DEROTE13DE08.global.corp.sap>
Message-ID: <CAP7YuAQDm0R2bj6vqj4TrsYJv4LyABbhUvdJRUauLgjs3z=vNw@mail.gmail.com>

Hi Goetz,

A few FOSDEM's ago a group of us came up with a *optional* (i.e. No one
should be forced to it) patch pipeline architecture where each vendor who
had specific platforms could pull patches from a queue, build them on their
specialised platform and return a result. This of course would require a
little bit of common infrastructure which the London Java Community (as a
non-profit entity) was willing to own/host on behalf of OpenJDK.

At the time there wasn't unanimous support for this idea (I imagine for
cost/resource reasons) from the major vendors involved in OpenJDK, but if
folks think this is a good time to revisit the discussion then perhaps we
could have a session on this at the upcoming 2017 FOSDEM.







Cheers,
Martijn

On 15 December 2016 at 07:18, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
wrote:

> > well.  Testing is embarrassingly parallel in principle so with enough
> > hardware (or one of those "clouds" everyone is selling these days) one
> > should be able to run arbitrarily many tests.  No one seems to deal well
>
> Hmm, is there a cloud containing all the different platforms?
> solarisx86_64? aixppc64?  linuxs390x? linuxarm32?
> I also think pre-submit testing is really helpful, but supplying the
> compute power on all these platforms to do this to an extend
> that you don't need any further testing is out of scope.
>
> Best regards,
>   Goetz.
>
>
>
>
>
> > -----Original Message-----
> > From: jdk10-dev [mailto:jdk10-dev-bounces at openjdk.java.net] On Behalf Of
> > Martin Buchholz
> > Sent: Thursday, December 15, 2016 5:26 AM
> > To: joe darcy <joe.darcy at oracle.com>
> > Cc: jdk10-dev at openjdk.java.net; quality-discuss at openjdk.java.net
> > Subject: Re: Repository? -- How many lines of development?
> >
> > On Wed, Dec 14, 2016 at 5:05 PM, joe darcy <joe.darcy at oracle.com> wrote:
> >
> > >
> > > The tiered testing efforts made earlier in JDK 9 [1] are necessary
> > > preconditions for a JDK-wide pre-push/pre-submit system. In
> particular, if
> > > you don't have a a set of meaningful tests that runs quickly enough and
> > > passes reliably enough then a pre-push system can cause more harm than
> > good
> > > in introducing bottlenecks and causing changes to be spuriously
> rejected,
> > > say by an existing intermittent failure unrelated to the change.
> > >
> >
> > It's a hard problem, but I think with sufficient effort presubmit can
> work
> > well.  Testing is embarrassingly parallel in principle so with enough
> > hardware (or one of those "clouds" everyone is selling these days) one
> > should be able to run arbitrarily many tests.  No one seems to deal well
> > with flaky tests, but flakiness can be measured, and a failing test can
> be
> > rerun arbitrarily, so deflaking should be automatable.
> >
> > At Google we are starting to experiment with running jtreg tests with
> > massive parallelism.
> >
> > Automation, presubmit testing and never-ever-broken master remain my
> > goals
> > for any software project.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161215/543b727d/attachment.html>

From vitaly.provodin at jetbrains.com  Wed Dec 21 04:25:58 2016
From: vitaly.provodin at jetbrains.com (Vitaly Provodin)
Date: Wed, 21 Dec 2016 11:25:58 +0700
Subject: What bug does JDK-8168389 duplicate?
Message-ID: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>

Good time of day

Recently I detected that the issue https://bugs.openjdk.java.net/browse/JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389> was closed as duplicate but there are no information about original bug.
Could you pleas provide information about what bug was duplicated by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?

Thanks,
Vitaly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161221/91de0cae/attachment.html>

From rory.odonnell at oracle.com  Wed Dec 21 10:21:39 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Wed, 21 Dec 2016 10:21:39 +0000
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
Message-ID: <2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>

Hi Vitaly,

I will look into this, the duplicate bug is JDK-8072110 - which was 
closed as "will not fix".

I will look into this further, but at this time of year it may take some 
time.

Rgds,Rory


On 21/12/2016 04:25, Vitaly Provodin wrote:
> Good time of day
>
> Recently I detected that the issue 
> https://bugs.openjdk.java.net/browse/JDK-8168389 was closed as 
> duplicate but there are no information about original bug.
> Could you pleas provide information about what bug was duplicated by 
> JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>
> Thanks,
> Vitaly

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161221/c652ab1c/attachment-0001.html>

From vitaly.provodin at jetbrains.com  Wed Dec 21 10:26:44 2016
From: vitaly.provodin at jetbrains.com (Vitaly Provodin)
Date: Wed, 21 Dec 2016 17:26:44 +0700
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
Message-ID: <B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>

Ooops. I do not have an access to JDK-8072110 - Bug System requires me to log in (but I do not have an account yet)
Does the issue JDK-8072110 have some restrictions?

> On 21 Dec 2016, at 17:21, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
> 
> Hi Vitaly,
> 
> I will look into this, the duplicate bug is JDK-8072110 - which was closed as "will not fix".
> 
> I will look into this further, but at this time of year it may take some time.
> 
> Rgds,Rory
> 
> On 21/12/2016 04:25, Vitaly Provodin wrote:
>> Good time of day
>> 
>> Recently I detected that the issue https://bugs.openjdk.java.net/browse/JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389> was closed as duplicate but there are no information about original bug.
>> Could you pleas provide information about what bug was duplicated by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>> 
>> Thanks,
>> Vitaly
> 
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161221/bd6d364b/attachment.html>

From rory.odonnell at oracle.com  Wed Dec 21 14:10:17 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Wed, 21 Dec 2016 14:10:17 +0000
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
	<B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>
Message-ID: <0d191d42-a7bb-d200-9209-84d33a1ece24@oracle.com>

Hi Vitaly,

You should be able to view the bug now, I am still looking into it.

Rgds,Rory


On 21/12/2016 10:26, Vitaly Provodin wrote:
> Ooops. I do not have an access to JDK-8072110 - Bug System requires me 
> to log in (but I do not have an account yet)
> Does the issue JDK-8072110 have some restrictions?
>
>> On 21 Dec 2016, at 17:21, Rory O'Donnell <rory.odonnell at oracle.com 
>> <mailto:rory.odonnell at oracle.com>> wrote:
>>
>> Hi Vitaly,
>>
>> I will look into this, the duplicate bug is JDK-8072110 - which was 
>> closed as "will not fix".
>>
>> I will look into this further, but at this time of year it may take 
>> some time.
>>
>> Rgds,Rory
>>
>>
>> On 21/12/2016 04:25, Vitaly Provodin wrote:
>>> Good time of day
>>>
>>> Recently I detected that the issue 
>>> https://bugs.openjdk.java.net/browse/JDK-8168389 was closed as 
>>> duplicate but there are no information about original bug.
>>> Could you pleas provide information about what bug was duplicated by 
>>> JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>>>
>>> Thanks,
>>> Vitaly
>>
>> -- 
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161221/444e4141/attachment.html>

From jonathan.gibbons at oracle.com  Wed Dec 21 15:47:26 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 21 Dec 2016 07:47:26 -0800
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
Message-ID: <3d96fcf8-b03b-5fc0-e6dc-9039097f2753@oracle.com>

Vitaly,

Look in the "Links" section:

Issue Links
duplicates
Bug - A problem which impairs or prevents the functions of the product. 
JDK-8072110 [embedded] Toolkit.realSync() forces a lot of graphical 
tests to fail on embedded devices     P4 - Minor loss of function, or 
other problem where easy workaround is present. Closed - The issue is 
considered finished, the resolution is correct. Issues which are closed 
can be reopened.

-- Jon



On 12/20/16 8:25 PM, Vitaly Provodin wrote:
> Good time of day
>
> Recently I detected that the issue 
> https://bugs.openjdk.java.net/browse/JDK-8168389 was closed as 
> duplicate but there are no information about original bug.
> Could you pleas provide information about what bug was duplicated by 
> JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>
> Thanks,
> Vitaly

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161221/2c2ceaff/attachment.html>

From vitaly.provodin at jetbrains.com  Thu Dec 22 02:25:02 2016
From: vitaly.provodin at jetbrains.com (Vitaly Provodin)
Date: Thu, 22 Dec 2016 09:25:02 +0700
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <0d191d42-a7bb-d200-9209-84d33a1ece24@oracle.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
	<B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>
	<0d191d42-a7bb-d200-9209-84d33a1ece24@oracle.com>
Message-ID: <C1F6B718-610A-4484-AADD-89983EA615D9@jetbrains.com>

Hi Rory,

Now it is accessed. But the  issue JDK-8168389 has resolution=?Cannot Reproduce? for now, before it was ?Duplicate?
Is that correct?

Thanks,
Vitaly

> On 21 Dec 2016, at 21:10, Rory O'Donnell <rory.odonnell at oracle.com> wrote:
> 
> Hi Vitaly,
> 
> You should be able to view the bug now, I am still looking into it.
> Rgds,Rory
> 
> On 21/12/2016 10:26, Vitaly Provodin wrote:
>> Ooops. I do not have an access to JDK-8072110 - Bug System requires me to log in (but I do not have an account yet)
>> Does the issue JDK-8072110 have some restrictions?
>> 
>>> On 21 Dec 2016, at 17:21, Rory O'Donnell <rory.odonnell at oracle.com <mailto:rory.odonnell at oracle.com>> wrote:
>>> 
>>> Hi Vitaly,
>>> 
>>> I will look into this, the duplicate bug is JDK-8072110 - which was closed as "will not fix".
>>> 
>>> I will look into this further, but at this time of year it may take some time.
>>> 
>>> Rgds,Rory
>>> 
>>> On 21/12/2016 04:25, Vitaly Provodin wrote:
>>>> Good time of day
>>>> 
>>>> Recently I detected that the issue https://bugs.openjdk.java.net/browse/JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389> was closed as duplicate but there are no information about original bug.
>>>> Could you pleas provide information about what bug was duplicated by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>>>> 
>>>> Thanks,
>>>> Vitaly
>>> 
>>> -- 
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland 
>> 
> 
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161222/11da00ee/attachment-0001.html>

From vitaly.provodin at jetbrains.com  Thu Dec 22 02:28:48 2016
From: vitaly.provodin at jetbrains.com (Vitaly Provodin)
Date: Thu, 22 Dec 2016 09:28:48 +0700
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <3d96fcf8-b03b-5fc0-e6dc-9039097f2753@oracle.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<3d96fcf8-b03b-5fc0-e6dc-9039097f2753@oracle.com>
Message-ID: <D5D540B5-E9D6-4A32-8A01-DF7ACE5892BF@jetbrains.com>

Jonathan,

Now I see JDK-8072110 in the ?Link? section but when I wrote the initial mail it was empty.
Now I got an answer on my question.

Thank you
Vitaly

> On 21 Dec 2016, at 22:47, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Vitaly,
> 
> Look in the "Links" section:
> 
> Issue Links
> duplicates
> Bug - A problem which impairs or prevents the functions of the product. JDK-8072110 [embedded] Toolkit.realSync() forces a lot of graphical tests to fail on embedded devices     P4 - Minor loss of function, or other problem where easy workaround is present.  Closed - The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.
> -- Jon
> 
> 
> On 12/20/16 8:25 PM, Vitaly Provodin wrote:
>> Good time of day
>> 
>> Recently I detected that the issue https://bugs.openjdk.java.net/browse/JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389> was closed as duplicate but there are no information about original bug.
>> Could you pleas provide information about what bug was duplicated by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>> 
>> Thanks,
>> Vitaly
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161222/0a2329cd/attachment.html>

From vitaly.provodin at jetbrains.com  Thu Dec 22 08:50:59 2016
From: vitaly.provodin at jetbrains.com (Vitaly Provodin)
Date: Thu, 22 Dec 2016 15:50:59 +0700
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <C1F6B718-610A-4484-AADD-89983EA615D9@jetbrains.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
	<B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>
	<0d191d42-a7bb-d200-9209-84d33a1ece24@oracle.com>
	<C1F6B718-610A-4484-AADD-89983EA615D9@jetbrains.com>
Message-ID: <D3008AA1-E802-49AF-8DA7-D320B28C4B8B@jetbrains.com>

The same issues with 
- https://bugs.openjdk.java.net/browse/JDK-8168294 <https://bugs.openjdk.java.net/browse/JDK-8168294>
- https://bugs.openjdk.java.net/browse/JDK-8025083 <https://bugs.openjdk.java.net/browse/JDK-8025083>
They were closed as a duplicate of some bugs - there are no information in the Links section (or it is inaccessible)

> On 22 Dec 2016, at 09:25, Vitaly Provodin <vitaly.provodin at jetbrains.com> wrote:
> 
> Hi Rory,
> 
> Now it is accessed. But the  issue JDK-8168389 has resolution=?Cannot Reproduce? for now, before it was ?Duplicate?
> Is that correct?
> 
> Thanks,
> Vitaly
> 
>> On 21 Dec 2016, at 21:10, Rory O'Donnell <rory.odonnell at oracle.com <mailto:rory.odonnell at oracle.com>> wrote:
>> 
>> Hi Vitaly,
>> 
>> You should be able to view the bug now, I am still looking into it.
>> Rgds,Rory
>> 
>> On 21/12/2016 10:26, Vitaly Provodin wrote:
>>> Ooops. I do not have an access to JDK-8072110 - Bug System requires me to log in (but I do not have an account yet)
>>> Does the issue JDK-8072110 have some restrictions?
>>> 
>>>> On 21 Dec 2016, at 17:21, Rory O'Donnell <rory.odonnell at oracle.com <mailto:rory.odonnell at oracle.com>> wrote:
>>>> 
>>>> Hi Vitaly,
>>>> 
>>>> I will look into this, the duplicate bug is JDK-8072110 - which was closed as "will not fix".
>>>> 
>>>> I will look into this further, but at this time of year it may take some time.
>>>> 
>>>> Rgds,Rory
>>>> 
>>>> On 21/12/2016 04:25, Vitaly Provodin wrote:
>>>>> Good time of day
>>>>> 
>>>>> Recently I detected that the issue https://bugs.openjdk.java.net/browse/JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389> was closed as duplicate but there are no information about original bug.
>>>>> Could you pleas provide information about what bug was duplicated by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>>>>> 
>>>>> Thanks,
>>>>> Vitaly
>>>> 
>>>> -- 
>>>> Rgds,Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA , Dublin, Ireland 
>>> 
>> 
>> -- 
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161222/7543e828/attachment.html>

From rory.odonnell at oracle.com  Thu Dec 22 10:02:44 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Thu, 22 Dec 2016 10:02:44 +0000
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <C1F6B718-610A-4484-AADD-89983EA615D9@jetbrains.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
	<B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>
	<0d191d42-a7bb-d200-9209-84d33a1ece24@oracle.com>
	<C1F6B718-610A-4484-AADD-89983EA615D9@jetbrains.com>
Message-ID: <92945331-2415-a476-11e6-5fefd46f3c58@oracle.com>


Hi Vitaly,

On 22/12/2016 02:25, Vitaly Provodin wrote:
> Hi Rory,
>
> Now it is accessed. But the  issue JDK-8168389 has resolution=?Cannot 
> Reproduce? for now, before it was ?Duplicate?
> Is that correct?
This is reproducible on WIndows, will get the bug updated later today.

Rgds,Rory
>
> Thanks,
> Vitaly
>
>> On 21 Dec 2016, at 21:10, Rory O'Donnell <rory.odonnell at oracle.com 
>> <mailto:rory.odonnell at oracle.com>> wrote:
>>
>> Hi Vitaly,
>>
>> You should be able to view the bug now, I am still looking into it.
>>
>> Rgds,Rory
>>
>>
>> On 21/12/2016 10:26, Vitaly Provodin wrote:
>>> Ooops. I do not have an access to JDK-8072110 - Bug System requires 
>>> me to log in (but I do not have an account yet)
>>> Does the issue JDK-8072110 have some restrictions?
>>>
>>>> On 21 Dec 2016, at 17:21, Rory O'Donnell <rory.odonnell at oracle.com 
>>>> <mailto:rory.odonnell at oracle.com>> wrote:
>>>>
>>>> Hi Vitaly,
>>>>
>>>> I will look into this, the duplicate bug is JDK-8072110 - which was 
>>>> closed as "will not fix".
>>>>
>>>> I will look into this further, but at this time of year it may take 
>>>> some time.
>>>>
>>>> Rgds,Rory
>>>>
>>>>
>>>> On 21/12/2016 04:25, Vitaly Provodin wrote:
>>>>> Good time of day
>>>>>
>>>>> Recently I detected that the issue 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8168389 was closed as 
>>>>> duplicate but there are no information about original bug.
>>>>> Could you pleas provide information about what bug was duplicated 
>>>>> by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>>>>>
>>>>> Thanks,
>>>>> Vitaly
>>>>
>>>> -- 
>>>> Rgds,Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA , Dublin, Ireland
>>>
>>
>> -- 
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161222/8b4fcf06/attachment-0001.html>

From rory.odonnell at oracle.com  Thu Dec 22 10:03:19 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Thu, 22 Dec 2016 10:03:19 +0000
Subject: What bug does JDK-8168389 duplicate?
In-Reply-To: <D3008AA1-E802-49AF-8DA7-D320B28C4B8B@jetbrains.com>
References: <FD684E49-8B52-4093-9B15-1F8DA99918CE@jetbrains.com>
	<2da0916f-2965-34b7-8adc-9322ba3eda46@oracle.com>
	<B126E1E4-9799-44AB-94C9-0CCB0D9DD5D4@jetbrains.com>
	<0d191d42-a7bb-d200-9209-84d33a1ece24@oracle.com>
	<C1F6B718-610A-4484-AADD-89983EA615D9@jetbrains.com>
	<D3008AA1-E802-49AF-8DA7-D320B28C4B8B@jetbrains.com>
Message-ID: <a7fd5298-7f7b-b9f3-5575-0dcb3f3fbf24@oracle.com>

Hi Vitaly,

Looking into these , will get back to you.

Rgds,Rory


On 22/12/2016 08:50, Vitaly Provodin wrote:
> The same issues with
> - https://bugs.openjdk.java.net/browse/JDK-8168294
> - https://bugs.openjdk.java.net/browse/JDK-8025083
> They were closed as a duplicate of some bugs - there are no 
> information in the Links section (or it is inaccessible)
>
>> On 22 Dec 2016, at 09:25, Vitaly Provodin 
>> <vitaly.provodin at jetbrains.com 
>> <mailto:vitaly.provodin at jetbrains.com>> wrote:
>>
>> Hi Rory,
>>
>> Now it is accessed. But the  issue JDK-8168389 has resolution=?Cannot 
>> Reproduce? for now, before it was ?Duplicate?
>> Is that correct?
>>
>> Thanks,
>> Vitaly
>>
>>> On 21 Dec 2016, at 21:10, Rory O'Donnell <rory.odonnell at oracle.com 
>>> <mailto:rory.odonnell at oracle.com>> wrote:
>>>
>>> Hi Vitaly,
>>>
>>> You should be able to view the bug now, I am still looking into it.
>>>
>>> Rgds,Rory
>>>
>>>
>>> On 21/12/2016 10:26, Vitaly Provodin wrote:
>>>> Ooops. I do not have an access to JDK-8072110 - Bug System requires 
>>>> me to log in (but I do not have an account yet)
>>>> Does the issue JDK-8072110 have some restrictions?
>>>>
>>>>> On 21 Dec 2016, at 17:21, Rory O'Donnell <rory.odonnell at oracle.com 
>>>>> <mailto:rory.odonnell at oracle.com>> wrote:
>>>>>
>>>>> Hi Vitaly,
>>>>>
>>>>> I will look into this, the duplicate bug is JDK-8072110 - which 
>>>>> was closed as "will not fix".
>>>>>
>>>>> I will look into this further, but at this time of year it may 
>>>>> take some time.
>>>>>
>>>>> Rgds,Rory
>>>>>
>>>>>
>>>>> On 21/12/2016 04:25, Vitaly Provodin wrote:
>>>>>> Good time of day
>>>>>>
>>>>>> Recently I detected that the issue 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8168389 was closed as 
>>>>>> duplicate but there are no information about original bug.
>>>>>> Could you pleas provide information about what bug was duplicated 
>>>>>> by JDK-8168389 <https://bugs.openjdk.java.net/browse/JDK-8168389>?
>>>>>>
>>>>>> Thanks,
>>>>>> Vitaly
>>>>>
>>>>> -- 
>>>>> Rgds,Rory O'Donnell
>>>>> Quality Engineering Manager
>>>>> Oracle EMEA , Dublin, Ireland
>>>>
>>>
>>> -- 
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>
>

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161222/47290353/attachment.html>

From rory.odonnell at oracle.com  Fri Dec 23 09:42:12 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 23 Dec 2016 09:42:12 +0000
Subject: Repository? -- How many lines of development?
In-Reply-To: <10c8f0e0-39dc-6323-170c-0779516dc743@oracle.com>
References: <52f370b5-79a7-7b11-b77c-0c1314812e9e@redhat.com>
	<11f471fa-87a6-f6e3-86b2-05467c076a5a@oracle.com>
	<CA+kOe0_7=CmP9WbEGfHM_kNirjf1dzjaTo4Z_Rz0wR0svv+Vxg@mail.gmail.com>
	<10c8f0e0-39dc-6323-170c-0779516dc743@oracle.com>
Message-ID: <2c94c049-784c-2827-fbdf-0b4d23e715b5@oracle.com>

Hi Martin,

We investigated the large number of failures in b146, the RMI failures 
were due to missing @build TestLibrary.

https://bugs.openjdk.java.net/browse/JDK-8170660

This issue was fixed in b148.

Rgds,Rory


On 29/11/2016 08:51, Rory O'Donnell wrote:
>
> Hi Martin,
>
>
> On 28/11/2016 20:15, Martin Buchholz wrote:
>>
>>
>> On Fri, Nov 18, 2016 at 8:33 AM, joe darcy <joe.darcy at oracle.com 
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>>     * A master forest, serving the roles master and dev play today in 9.
>>
>>     With a few exceptions, in JDK 9 master was just time-delayed copy
>>     of dev so we can implement recording the  information about which
>>     set of sources correspond to a promoted build without using a
>>     whole other forest.
>>
>>     Rather than using a separate line of development for client-libs
>>     work as in 9, I think this should be done in the same line of
>>     development as all other libs work in 10.
>>
>>
>> For many years, I've been advocating having a guaranteed 
>> always-working, never regressing master and also always a place for 
>> developers to submit-and-forget their (possibly slightly buggy) 
>> changes.  All regressions that could be caught by a test are 100% 
>> guaranteed to be caught by a competent trusted release engineer who 
>> is the only one ever moving changes into the master forest.  Based on 
>> this idea, it seems essential to have something like a jdk10-dev 
>> forest (it could also be implemented using mercurial branches, but 
>> that would be a break with many decades of tradition).
>>
>> I notice today the message
>> http://mail.openjdk.java.net/pipermail/quality-discuss/2016-November/000596.html
>> where regressions have crept into a jdk9 build, which is 
>> disappointing.  The whole point of regression testing is to ensure 
>> that regressions don't happen!  And I recall having that job myself 
>> back in 2005!
> We are investigating these failures.
>
> The reason for posting results, warts and all, is to allow others to 
> have results to compare with.
> The number of failures , in this instance, is unusually high.
>
> Rgds,Rory
>
>
> -- 
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161223/98be93de/attachment.html>

From abdul.kolarkunnu at oracle.com  Fri Dec 23 10:11:06 2016
From: abdul.kolarkunnu at oracle.com (Muneer Kolarkunnu)
Date: Fri, 23 Dec 2016 02:11:06 -0800 (PST)
Subject: JDK 9 build 149 test results now available
Message-ID: <8e54e7b2-7620-462c-91ae-e18959922527@default>

 

JDK 9 ea build 149 test results are now available at 
http://www.java.net/download/openjdk/testresults/9/testresults.html

The jdk test results contain 149 differences from the build 146 test results.

No new testcase failures found.

0: /home/jtest/merge9/146/jdk/JTwork  pass: 6,004; fail: 71; not run: 2,206

1: /home/jtest/merge9/149/jdk/JTwork  pass: 6,130; fail: 7; not run: 2,195

 

0      1      Test

pass   ---    com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java

---    pass   java/io/FilePermission/MergeName.java

---    pass   java/lang/Class/attributes/ClassAttributesTest.java

---    pass   java/lang/ClassLoader/GetResourceNullArg.java

---    pass   java/lang/instrument/RedefineModuleTest.java

---    pass   java/lang/instrument/modules/AppendToClassPathModuleTest.java

---    pass   java/lang/invoke/MethodHandles/privateLookupIn/Driver.java

---    pass   java/lang/reflect/Layer/LayerControllerTest.java

---    pass   java/lang/reflect/Module/AnnotationsTest.java

---    pass   java/lang/reflect/Module/annotation/Basic.java

---    pass   java/net/Authenticator/B4933582.java

pass   ---    java/net/Authenticator/B4933582.sh

---    pass   java/net/Authenticator/GetAuthenticatorTest.java

---    pass   java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java

---    pass   java/net/HttpURLConnection/SetAuthenticator/HTTPTest.java

---    pass   java/net/InetAddress/ptr/Lookup.java

pass   ---    java/net/InetAddress/ptr/lookup.sh

---    pass   java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java

pass   ---    java/net/ServerSocket/AcceptCauseFileDescriptorLeak.sh

---    pass   java/net/SocketOption/MinimumRcvBufferSize.java

---    pass   java/net/httpclient/APIErrors.java

---    pass   java/net/httpclient/BasicAuthTest.java

---    pass   java/net/httpclient/HeadersTest.java

---    pass   java/net/httpclient/HeadersTest1.java

---    pass   java/net/httpclient/HttpInputStreamTest.java

---    pass   java/net/httpclient/HttpRequestBuilderTest.java

---    pass   java/net/httpclient/ImmutableHeaders.java

---    pass   java/net/httpclient/ManyRequests.java

---    pass   java/net/httpclient/MessageHeadersTest.java

---    pass   java/net/httpclient/MultiAuthTest.java

---    pass   java/net/httpclient/ProxyAuthTest.java

---    pass   java/net/httpclient/RequestBodyTest.java

---    pass   java/net/httpclient/ShortRequestBody.java

---    pass   java/net/httpclient/SmokeTest.java

---    pass   java/net/httpclient/SplitResponse.java

---    pass   java/net/httpclient/TestKitTest.java

---    pass   java/net/httpclient/TimeoutOrdering.java

---    pass   java/net/httpclient/examples/WebSocketExample.java

---    pass   java/net/httpclient/http2/BasicTest.java

---    pass   java/net/httpclient/http2/ErrorTest.java

---    pass   java/net/httpclient/http2/HpackDriver.java

---    pass   java/net/httpclient/http2/HpackDriverHeaderTable.java

---    pass   java/net/httpclient/http2/NoBody.java

---    pass   java/net/httpclient/http2/RedirectTest.java

---    pass   java/net/httpclient/http2/ServerPush.java

---    pass   java/net/httpclient/http2/TLSConnection.java

---    pass   java/net/httpclient/http2/Timeout.java

---    pass   java/net/httpclient/security/Driver.java

---    pass   java/net/httpclient/security/Security.java

---    pass   java/net/httpclient/websocket/WSDriver.java

---    pass   java/net/httpclient/whitebox/Driver.java

fail   pass   java/rmi/Naming/UnderscoreHost.java

fail   pass   java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java

fail   pass   java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java

fail   pass   java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java

fail   pass   java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java

fail   pass   java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.java

fail   pass   java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.java

fail   pass   java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java

fail   pass   java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.java

fail   pass   java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.java

fail   pass   java/rmi/activation/Activatable/nestedActivate/NestedActivate.java

fail   pass   java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java

fail   pass   java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.java

fail   pass   java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.java

fail   pass   java/rmi/activation/Activatable/restartService/RestartService.java

fail   pass   java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java

fail   pass   java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.java

fail   pass   java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java

fail   pass   java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java

fail   pass   java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java

fail   pass   java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java

fail   pass   java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java

fail   pass   java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java

fail   pass   java/rmi/activation/CommandEnvironment/SetChildEnv.java

fail   pass   java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java

fail   ---    java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java

fail   pass   java/rmi/registry/classPathCodebase/ClassPathCodebase.java

fail   pass   java/rmi/registry/emptyName/EmptyName.java

fail   pass   java/rmi/registry/interfaceHash/InterfaceHash.java

fail   pass   java/rmi/reliability/juicer/AppleUserImpl.java

fail   pass   java/rmi/server/RMIClassLoader/delegateBeforePermissionCheck/DelegateBeforePermissionCheck.java

fail   pass   java/rmi/server/RMIClassLoader/delegateToContextLoader/DelegateToContextLoader.java

fail   pass   java/rmi/server/RMIClassLoader/downloadArrayClass/DownloadArrayClass.java

fail   pass   java/rmi/server/RMIClassLoader/getClassLoader/GetClassLoader.java

fail   pass   java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java

fail   pass   java/rmi/server/RMIClassLoader/spi/ContextInsulation.java

fail   pass   java/rmi/server/RMIClassLoader/spi/DefaultProperty.java

fail   pass   java/rmi/server/RMIClassLoader/spi/Installed.java

fail   pass   java/rmi/server/RMIClassLoader/spi/InvalidProperty.java

fail   pass   java/rmi/server/RMIClassLoader/spi/Property.java

fail   pass   java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java

fail   pass   java/rmi/server/RMIClassLoader/useGetURLs/UseGetURLs.java

fail   pass   java/rmi/server/RMISocketFactory/useSocketFactory/activatable/UseCustomSocketFactory.java

fail   pass   java/rmi/server/RMISocketFactory/useSocketFactory/registry/UseCustomSocketFactory.java

fail   pass   java/rmi/server/RMISocketFactory/useSocketFactory/unicast/UseCustomSocketFactory.java

fail   pass   java/rmi/server/RemoteObject/verifyRemoteEquals/VerifyRemoteEquals.java

fail   pass   java/rmi/server/UnicastRemoteObject/unexportObject/UnexportLeak.java

fail   pass   java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java

fail   pass   java/rmi/server/Unreferenced/unreferencedContext/UnreferencedContext.java

fail   pass   java/rmi/server/clientStackTrace/ClientStackTrace.java

fail   pass   java/rmi/transport/closeServerSocket/CloseServerSocket.java

fail   pass   java/rmi/transport/dgcDeadLock/DGCDeadLock.java

fail   pass   java/rmi/transport/handshakeFailure/HandshakeFailure.java

fail   pass   java/rmi/transport/handshakeTimeout/HandshakeTimeout.java

fail   pass   java/rmi/transport/pinClientSocketFactory/PinClientSocketFactory.java

fail   pass   java/rmi/transport/reuseDefaultPort/ReuseDefaultPort.java

---    pass   java/security/ProtectionDomain/NullGetActions.java

---    pass   java/security/SecureRandom/NoSync.java

---    pass   java/security/SecureRandom/ThreadSafe.java

---    pass   java/util/ArrayList/IteratorMicroBenchmark.java

---    pass   java/util/Collection/IteratorMicroBenchmark.java

---    pass   java/util/Collection/RemoveMicroBenchmark.java

---    pass   java/util/Locale/Bug8071929.java

---    pass   java/util/ResourceBundle/modules/cache/CacheTest.java

---    pass   java/util/ResourceBundle/modules/unnamed/unnamed.sh

pass   ---    java/util/ServiceLoader/basic.sh

---    pass   java/util/ServiceLoader/basic/basic.sh

---    pass   java/util/ServiceLoader/modules/BadProvidersTest.java

---    pass   java/util/ServiceLoader/modules/Basic.java

pass   ---    java/util/ServiceLoader/modules/MiscTests.java

pass   ---    java/util/ServiceLoader/modules/ServicesTest.java

---    pass   java/util/Spliterator/SpliteratorFailFastTest.java

pass   ---    java/util/Spliterator/SpliteratorLateBindingFailFastTest.java

---    pass   java/util/Spliterator/SpliteratorLateBindingTest.java

---    pass   javax/crypto/CryptoPermissions/CryptoPolicyFallback.java

---    pass   javax/imageio/plugins/tiff/ReadWithoutBaselineTagSet.java

fail   pass   javax/management/remote/mandatory/connection/RMIConnector_NPETest.java

---    pass   javax/net/ssl/finalize/SSLSessionFinalizeTest.java

pass   ---    javax/net/ssl/templates/SSLSocketSample.java

pass   ---    javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java

---    pass   javax/sound/sampled/AudioFileFormat/TypeEqualsToNull.java

---    pass   javax/sound/sampled/AudioFormat/EncodingEqualsToNull.java

---    pass   javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java

pass   ---    javax/xml/ws/clientjar/TestWsImport.java

---    pass   jdk/modules/open/Basic.java

fail   pass   sun/rmi/rmic/iiopCompilation/IIOPCompilation.java

fail   pass   sun/rmi/runtime/Log/4504153/Test4504153.java

fail   pass   sun/rmi/runtime/Log/6409194/NoConsoleOutput.java

fail   pass   sun/rmi/runtime/Log/checkLogging/CheckLogStreams.java

fail   pass   sun/rmi/runtime/Log/checkLogging/CheckLogging.java

fail   pass   sun/rmi/server/MarshalOutputStream/marshalForeignStub/MarshalForeignStub.java

fail   pass   sun/rmi/transport/tcp/DeadCachedConnection.java

---    pass   tools/jar/multiRelease/Basic1.java

---    pass   tools/jimage/JImageBasicsTest.java

---    pass   tools/jimage/JImageInfoTest.java

---    pass   tools/jlink/basic/AllModulePath.java

---    pass   tools/launcher/InfoStreams.java

---    pass   tools/launcher/modules/addexports/manifest/AddExportsAndOpensInManifest.java

 

149 differences

 

The hotspot test results contain 8 differences from the build 146 test results.

No new testcase failures found.

0: /home/jtest/merge9/146/hotspot/JTwork  pass: 1,340; fail: 7; error: 15; not run: 54

1: /home/jtest/merge9/149/hotspot/JTwork  pass: 1,339; fail: 5; error: 19; not run: 54

 

0      1      Test

pass   ---    runtime/modules/JVMCanReadModule.java

pass   ---    runtime/modules/JVMIsExportedToModule.java

---    error  serviceability/jvmti/AddModuleExportsAndOpens/MyPackage/AddModuleExportsAndOpensTest.java

---    error  serviceability/jvmti/AddModuleReads/MyPackage/AddModuleReadsTest.java

---    error  serviceability/jvmti/AddModuleUsesAndProvides/MyPackage/AddModuleUsesAndProvidesTest.java

fail   pass   serviceability/sa/TestInstanceKlassSize.java

fail   pass   serviceability/sa/TestInstanceKlassSizeForInterface.java

pass   error  serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java

 

8 differences

 

The langtools test results contain 21 differences from the build 146 test results. There are 4
testcase failures, these failures are under investigation.

0: /home/jtest/merge9/146/langtools/JTwork  pass: 3,516; not run: 277

1: /home/jtest/merge9/149/langtools/JTwork  pass: 3,527; fail: 4; not run: 290

 

0      1      Test

---    pass   tools/javac/T8170667/ParameterProcessor.java

---    pass   tools/javac/api/TestName.java

---    pass   tools/javac/boxing/QualBoxedPostOp.java

---    pass   tools/javac/boxing/QualBoxedPostOp2.java

---    pass   tools/javac/boxing/QualBoxedPostOp3.java

---    pass   tools/javac/desugar/BoxingAndSuper.java

---    pass   tools/javac/generics/inference/8170410/T8170410.java

---    pass   tools/javac/modules/AllDefaultTest.java

---    pass   tools/javac/modules/AnnotationsOnModules.java

---    pass   tools/javac/modules/GetLocationForModuleTest.java

---    pass   tools/javac/modules/OpenModulesTest.java

pass   ---    tools/javac/modules/RequiresPublicTest.java

---    pass   tools/javac/modules/RequiresStaticTest.java

---    pass   tools/javac/modules/RequiresTransitiveTest.java

pass   fail   tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.java

---    pass   tools/javac/processing/model/LocalInAnonymous.java

---    pass   tools/javadoc/BadOptionsTest.java

---    pass   tools/jdeps/modules/GenOpenModule.java

pass   fail   tools/sjavac/ApiExtraction.java

pass   fail   tools/sjavac/ClasspathDependencies.java

pass   fail   tools/sjavac/IgnoreSymbolFile.java

 

21 differences

 

The nashorn test result is available at
http://download.java.net/openjdk/testresults/9/archives/149/emailable-report.html

-- 
Regards,
Abdul Muneer
Quality Engineer
Oracle, Bangalore, India 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161223/41442cab/attachment-0001.html>