There is a regression test that is supposed to catch this exact problem.
So I had looked into how we did not catch this earlier and found that in
fact we did.
This was originally found and filed as
https://bugs.openjdk.java.net/browse/JDK-8224825
The test java/awt/Color/AlphaColorTest.java was then problem listed on
Linux.
$ grep AlphaColorTest test/jdk/ProblemList.txt
java/awt/Color/AlphaColorTest.java 8224825 linux-all
So I think we can close JDK-8224825 as a duplicate of this as well as
updating the problem list
and the test - after confirming that this backout resolves that as I
expect it will.
-phil.
On 7/11/19, 9:20 AM, Anton Litvinov wrote:
By your request regenerated the webrev specifically against
(http://hg.openjdk.java.net/jdk/jdk13) repository.
JDK 13 specific webrev:
http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00
I confirm again, that 2 failing manual tests: "ColorTest0003",
"ColorTest0004" from the test
"api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail
anymore after this fix is applied to JDK 13 compiled from "jdk/jdk13"
repository.
"jdk/jdk13" repository does not contain any problem list mentioning
"api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I
cannot de-problem list it and have no idea, where it is
problem-listed. I also doubt that it is problem-listed, since it is
manual. I added "noreg-jck" label to the bug in JBS deliberately
according to OpenJDK process (Section #6 from the web page
(http://openjdk.java.net/guide/changePlanning.html)), because this
back out fix does not contain a new separate regression test, while
this regression can be checked by running existing mentioned above
test from JCK package.
If this "noreg-jck" label creates problems, I can remove it at all.
Thank you,
Anton
On 11/07/2019 15:51, Philip Race wrote:
One more thing I just realised you should do here is de-problem list
the regression test that fails ... after verifying it now works,
updating it with this bug ID.
And you can remove that noreg-jck label as a consequence.
-phil.
On 7/11/19, 7:35 AM, Philip Race wrote:
In such cases I like more than to be told "it would apply cleanly"
but also to see
that you actually prepared the webrev against 13. This is more certain
and ensures that when the fix is approved you don't accidentally
push it
to the wrong repo. You have to go clone 13 and apply the patch there
anyway ...
-phil.
On 7/11/19, 5:44 AM, Anton Litvinov wrote:
Hello Phil,
Thank you for review and the important remark about the need to
work with "jdk/jdk13" stabilization repository, I forgot about this
feature of post RDP 1 phase. Today I checked the fix against
"jdk/jdk13" repository and confirm that it resolves this bug for
JDK 13.
Will wait for feedback or approval from any other second code
reviewer.
Thank you,
Anton
On 10/07/2019 19:55, Phil Race wrote:
Anton,
This looks fine except that it needs to be prepared against 13,
and then pushed there, not 14.
And it will get forwarded synced from 13 to 14. That is the RDP
process ..
-phil.
On 7/10/19 5:00 AM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug. The fix is
backing out of the fix for the bug JDK-8214579 which caused this
JCK test failure. If this fix is accepted, then a new separate
bug for readdressing the bug reported in JDK-8214579 will be filed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227392
Webrev:
http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00
Changeset of JDK-8214579:
http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57
Thank you,
Anton
