[OpenJDK 2D-Dev] <Swing Dev> [12] Review Request: 8213110 Remove the use of applets in automatic tests

Philip Race philip.race at oracle.com
Sat Feb 23 23:49:40 UTC 2019


OK then this is fine.

-phil.

On 2/14/19, 10:32 PM, Sergey Bylokhov wrote:
> On 30/01/2019 14:53, Phil Race wrote:
>> Oh .. and I meant to ask what probably is an obvious question but 
>> needs to be asked anyway.
>> You say you did not try to fix tests that already fail - this is just 
>> a conversion - but did you
>> confirm there are no NEW failures on any platform ?
>
> Yes, there are no tests which passed before the fix and fails after.
>
>>
>> -phil.
>>
>> On 1/30/19 2:29 PM, Phil Race wrote:
>>>
>>> You discuss the life cycle of an applet in jtreg
>>> -----------
>>>   - Call init() and start() methods of the Applet
>>>   - Waits for 2 seconds
>>>   - Call stop() and destroy() methods of the Applet
>>>   - Dispose the frame
>>> ------
>>>
>>> I see init() and start() being used but I don't see the rest 
>>> replaced. Why not ?
>>> Do you really mean jtreg() kills the applet just two seconds after 
>>> start() returns ?
>>>
>>>
>>> For the tests where you do something like
>>>  main(...) {
>>> ....
>>> obj.init();
>>> obj.start();
>>>
>>> eg here :
>>> http://cr.openjdk.java.net/~serb/8213110/webrev.04/test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java.sdiff.html 
>>>
>>> would it make sense to invoke that code on the EDT instead of the 
>>> main thread ?
>>>
>>> EventQueue.invokeLater(new Runnable() {
>>> Like already happens here :
>>> http://cr.openjdk.java.net/~serb/8213110/webrev.04/test/jdk/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java.sdiff.html 
>>>
>>> We have lots of AWT tests that use the main thread so not a blocker 
>>> but just a question and
>>> likely could mean further updates to some tests are needed if an 
>>> exception no longer propagates
>>> on an expected thread.
>>>
>>>
>>> -phil.
>>>
>>> On 11/26/18 6:29 PM, Sergey Bylokhov wrote:
>>>> The "ProblemList.txt" is updated in the new version:
>>>> http://cr.openjdk.java.net/~serb/8213110/webrev.04
>>>>
>>>> On 08/11/2018 10:57, Sergey Bylokhov wrote:
>>>>> Note that for some of the tests I'll need to update the problem 
>>>>> list and replace the .html by the .java.
>>>>> But since we actively updates the problem lists right now I 
>>>>> postponed this task for a weekend.
>>>>>
>>>>> On 07/11/2018 15:47, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review the fix for jdk 12.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213110
>>>>>> Webrev: http://cr.openjdk.java.net/~serb/8213110/webrev.03
>>>>>>
>>>>>> Description of the bug:
>>>>>>    A number of our tests in jdk still launch by applets via "@run 
>>>>>> applet".
>>>>>> Usually we drop this usage when we update the test for some 
>>>>>> reason, and
>>>>>> in this fix we will drop them completely for automated tests from 
>>>>>> the open repo.
>>>>>> I did not update the tests which are specific for Applet API, 
>>>>>> manual tests, or tests
>>>>>> which are currently under review for some other bugs.
>>>>>>
>>>>>> Note: the "@run applet" means, that the jtreg will do these steps:
>>>>>>   - Creates a frame as a holder for the Applet
>>>>>>   - Creates an applet(which is undecorated panel) and adds it to 
>>>>>> the frame
>>>>>>   - Sets the size of the frame
>>>>>>   - Place the frame to the center of the screen
>>>>>>   - Make the frame visible
>>>>>>   - Call init() and start() methods of the Applet
>>>>>>   - Waits for 2 seconds
>>>>>>   - Call stop() and destroy() methods of the Applet
>>>>>>   - Dispose the frame
>>>>>>
>>>>>>
>>>>>> Description of the fix:
>>>>>>
>>>>>>   - In all cases the usage of the Applet API was dropped
>>>>>>   - In the common case when the applet was used as launcher, this 
>>>>>> code now used instead:
>>>>>>     public static void main(final String[] args) {
>>>>>>        TestName app = new TestName();
>>>>>>        app.init();
>>>>>>        app.start();
>>>>>>     }
>>>>>>     Example:
>>>>>> http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.java.sdiff.html 
>>>>>>
>>>>>>
>>>>>>   - In some cases it was possible to replace init()/start() by 
>>>>>> the simple main() method.
>>>>>>     Example:
>>>>>> http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java.sdiff.html 
>>>>>>
>>>>>>
>>>>>>   - Some of the tests were used the "extend Applet" w/o a reasons:
>>>>>>     Example:
>>>>>> http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java.sdiff.html 
>>>>>>
>>>>>>
>>>>>>   - Some of the tests shows the applet window(which was unrelated 
>>>>>> to the test itself) in the center of the screen.
>>>>>>     Example:
>>>>>> http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java.sdiff.html 
>>>>>>
>>>>>>
>>>>>>   - Some of the tests uses the applet as a place holder for the 
>>>>>> test components.
>>>>>>     In this case it was necessary to change the Applet API to the 
>>>>>> Frame API, and complete
>>>>>>     the steps which were done by the jtreg:
>>>>>>     Example:
>>>>>> http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java.sdiff.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>> Notes:
>>>>>>   - To simplify the review I tried to not change the logic of the 
>>>>>> tests,
>>>>>>     so if the test fail before the fix, then it will fail after 
>>>>>> the fix.
>>>>>>     I would like to create the separate CRs for all additional(if 
>>>>>> any) cleanup of these tests.
>>>>>>   - Just a few exception from the above is additional calls to:
>>>>>>     "setLocationRelativeTo" to place the window to the center of 
>>>>>> the screen
>>>>>>     "robot.waitForIdle()"/"setUndecorated()" to make the tests 
>>>>>> more stable(when I compared the tests before/after the fix)
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>


More information about the 2d-dev mailing list