On Wed, Nov 23, 2016 at 7:39 PM, Philip Race wrote:
> We have a PIT (pre-integration-testing process) but if
> that these clashes are presented only as an FYI and not
> an actual failure then SQE might not notice it. It may
> even get swallowed and not forwarded for human inspection
> by some lay
That bears investigation ... next week,
-- Jon
On 11/23/2016 07:39 PM, Philip Race wrote:
We have a PIT (pre-integration-testing process) but if
that these clashes are presented only as an FYI and not
an actual failure then SQE might not notice it. It may
even get swallowed and not forwarded fo
We have a PIT (pre-integration-testing process) but if
that these clashes are presented only as an FYI and not
an actual failure then SQE might not notice it. It may
even get swallowed and not forwarded for human inspection
by some layered tool on top.
I don't actually know .. I am just speculatin
At least in part, it's related to the underlying JavaTest harness.
It would be good to improve things in this area.
There are a bunch of options which are now "strange defaults", but I
don't know how much problems we would cause to change. For example,
1. othervm is now the default, but I rec
On Wed, Nov 23, 2016 at 1:34 PM, Phil Race wrote:
> Hi,
>
> So your real complaint isn't the failure itself, but that jtreg bothers
> to check directories you aren't even running tests from, and
> that is a time tax whether such clashes exist or not ?
> Seems a reasonable point ... if I'm running
Thank you! My own jtreg running infrastructure now uses -noreport as the
default.
It's a little surprising that report generation is a global operation while
test running is "local", although it's understandable because jtreg wants
to report all tests NOT run as well. I don't see this explained
Actually, jtreg is (has always been) optimised to *run* tests
efficiently, with no time tax.
But yes, there is a time tax, which comes from writing the report at the
end of the test run, and that is actually where the clash is (probably)
being detected.
And, my guess is that a developer runnin
Hi,
So your real complaint isn't the failure itself, but that jtreg bothers
to check directories you aren't even running tests from, and
that is a time tax whether such clashes exist or not ?
Seems a reasonable point ... if I'm running a single Image I/O test
jtreg still finds the java/awt clash
On 11/23/2016 12:47 PM, Martin Buchholz wrote:
Am I the only one seeing jtreg test failures in latest jdk9/dev,
apparently due to
https://bugs.openjdk.java.net/browse/JDK-8160766
Error: Test clashes with another test with a similar name:
.../jdk/test/java/awt/Focus/DisposedWindow/DisposeDial
Jonathan: Here's a small jtreg feature request:
It's nice for release engineers to have jtreg check the whole test/ tree
for correct test definitions. But for developers who are just doing
jtreg MyTest.java
they're not interested in awt failures, and don't want to pay the 10-second
tax to check
The bug Martin referenced has a link to another bug which reports this
clash :
https://bugs.openjdk.java.net/browse/JDK-8169840
-phil.
On 11/23/2016 12:57 PM, Jonathan Gibbons wrote:
On 11/23/2016 12:47 PM, Martin Buchholz wrote:
Am I the only one seeing jtreg test failures in latest jdk9/de
Am I the only one seeing jtreg test failures in latest jdk9/dev, apparently
due to
https://bugs.openjdk.java.net/browse/JDK-8160766
Error: Test clashes with another test with a similar name:
.../jdk/test/java/awt/Focus/DisposedWindow/DisposeDialogNotActivateOwnerTest/DisposeDialogNotActivateOwner
On 23.11.16 18:37, Semyon Sadetsky wrote:
On 22.11.2016 02:06, Sergey Bylokhov wrote:
Hi, Semyon.
Why did you change the code to load the property each time the robot
will be created? I guess it is possible to change only the line in the
static block, so absent of "awt.robot.gtk" will mean use
On 22.11.2016 02:06, Sergey Bylokhov wrote:
Hi, Semyon.
Why did you change the code to load the property each time the robot
will be created? I guess it is possible to change only the line in the
static block, so absent of "awt.robot.gtk" will mean use GTK.
I did this small refactoring because
+1
--Semyon
On 23.11.2016 17:24, Sergey Bylokhov wrote:
On 23.11.16 17:23, Anton Tarasov wrote:
It actually won't work, because m_visible is set ahead:
AwtFrame::Show()
{
m_visible = true;
<...>
::ShowWindow(hwnd);
}
The latter call causes WM_SHOWWINDOW and causes
AwtFrame::WmShowWi
On 23.11.16 17:23, Anton Tarasov wrote:
It actually won't work, because m_visible is set ahead:
AwtFrame::Show()
{
m_visible = true;
<...>
::ShowWindow(hwnd);
}
The latter call causes WM_SHOWWINDOW and causes
AwtFrame::WmShowWindow(BOOL show, UINT status).
So we have [window->isVisible
Hi Sergey,
On 11/23/2016 4:57 PM, Sergey Bylokhov wrote:
Hi, Anton.
On 23.11.16 13:08, Anton Tarasov wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8140525
webrev: http://cr.openjdk.java.net/~ant/JDK-8140525/webrev.0
Please find the description in the bug. This comment explains the fix:
Hello.
Please review the fix for jdk9.
Support of WM_MOUSEHWHEEL for Swing was added (AWT components were not
touched), which mostly the code symmetric to the WM_MOUSEWHEEL, except
that I changed the direction to align it in Swing and OS. It seems that
this functionality does not work on linu
Hi, Anton.
On 23.11.16 13:08, Anton Tarasov wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8140525
webrev: http://cr.openjdk.java.net/~ant/JDK-8140525/webrev.0
Please find the description in the bug. This comment explains the fix:
One question just to clarify the fix. Are there differenc
Hello,
Please review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8140525
webrev: http://cr.openjdk.java.net/~ant/JDK-8140525/webrev.0
Please find the description in the bug. This comment explains the fix:
https://bugs.openjdk.java.net/browse/JDK-8140525?focusedCommentId=13865151&pag
20 matches
Mail list logo
