Hi Sean,
On 27.03.2012 7:22, Sean Chou wrote:
Hi Anthony,
I tried the scenario you suggested, but it doesn't work. And I found the
jtreg spec says:
' A "main" action is
considered to be finished when the main method returns; if a test involves
multiple threads, some synchronization may be necessary to ensure that the
other threads finish their work before the thread running the main method
returns. '
Then I tried to join TimerQueue in main, but it always blocks. So I started
a new process
to wait instead.
TimerQueue is a package private class which assumes reflection which I would
avoid using by any means.
I personally don't see any strong reason why you shouldn't use the Runtime stuff (taking into
account the jtreg behavior). Anthony, do you?
I tested and found the "/" separated path works on windows, it is not a
problem :)
I looked at the implementation of Runtime.exec(String) just for curiosity. It (in its deep)
normalizes the path via File.getPath(), so using slash seems ok.
Thanks,
Anton.
On Mon, Mar 26, 2012 at 9:55 PM, Anthony Petrov <anthony.pet...@oracle.com
<mailto:anthony.pet...@oracle.com>> wrote:
Hi Sean,
92 worker =
Runtime.getRuntime().exec(System.getProperty("java.home")+"/bin/java
TestDispose
workprocess");
This won't work on MS Windows because the path separator character is
different there.
Actually, I don't understand why you need this Runtime stuff in the first
place. If test JVM
doesn't terminate, the test will fail. So why not create a frame and a text
field right in the
main(), then call dispose() and return from main()? Since the timer thread
will still be
running, the test's JVM won't exit, and the test will fail by timeout
eventually. Will this
testing scenario work?
--
best regards,
Anthony
On 03/23/12 10:49, Sean Chou wrote:
I modified the testcase according to Anthony Petrov's
suggestion(http://mail.openjdk.java.net/pipermail/awt-dev/2012-March/002389.html)
.
The new webrev: http://cr.openjdk.java.net/~zhouyx/7155298/webrev.02/
<http://cr.openjdk.java.net/%7Ezhouyx/7155298/webrev.02/>
However, the timeout action in jtreg only checks the main method, but
the timeout is caused by timer thread .
So, I started an other process to run the testcase and the main testcase
waitFor that process to stop. In order to kill the process started by
the testcase, I added a ShutdownHook to the runtime of main testcase.
And added /othervm action to testcase .
It seems the testcase is a little over complex, is there any other
method to make the testcase simpler ?
On Fri, Mar 23, 2012 at 2:04 AM, Oleg Sukhodolsky <son....@gmail.com
<mailto:son....@gmail.com>
<mailto:son....@gmail.com <mailto:son....@gmail.com>>> wrote:
On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov
<anton.tara...@oracle.com <mailto:anton.tara...@oracle.com>
<mailto:anton.tara...@oracle.com <mailto:anton.tara...@oracle.com>>>
wrote:
> On 3/22/12 6:15 PM, Oleg Sukhodolsky wrote:
>>
>> On Thu, Mar 22, 2012 at 5:55 PM, Anton V. Tarasov
>> <anton.tara...@oracle.com <mailto:anton.tara...@oracle.com>
<mailto:anton.tara...@oracle.com <mailto:anton.tara...@oracle.com>>>
wrote:
>>>
>>> On 22.03.2012 14:37, Oleg Sukhodolsky wrote:
>>>>
>>>> On Thu, Mar 22, 2012 at 2:19 PM, Anton V. Tarasov
>>>> <anton.tara...@oracle.com <mailto:anton.tara...@oracle.com>
<mailto:anton.tara...@oracle.com <mailto:anton.tara...@oracle.com>>>
wrote:
>>>>>
>>>>> On 22.03.2012 12:47, Oleg Sukhodolsky wrote:
>>>>>>
>>>>>> On Thu, Mar 22, 2012 at 12:01 PM, Sean
Chou<zho...@linux.vnet.ibm.com <mailto:zho...@linux.vnet.ibm.com>
<mailto:zho...@linux.vnet.ibm.com <mailto:zho...@linux.vnet.ibm.com>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> Seem there are misunderstanding .
>>>>>>> DefaultCaret can receive FocusLostEvent when another
control get
>>>>>>> focused. But it
>>>>>>> doesn't receive FocusLostEvent when disposing.
>>>>>>>
>>>>>>> The reason is XTextAreaPeer doesn't receive
FocusLostEvent when
>>>>>>> disposing. But
>>>>>>> I don't know if it is a rule that a FocusLostEvent must be
sent to
>>>>>>> the
>>>>>>> focused>>> component when the top-level window is disposed ?
>>>>>>
>>>>>> Well, for regular AWT component it is expected. And I'd
expect that
>>>>>> this should also be true for peer.
>>>>>
>>>>>
>>>>> That's right, focus_lost should be dispatched to a disposed focus
>>>>> owner.
>>>>
>>>> So, now we need to figure out why the caret doesn't get the event.
>>>>
>>>> Oleg.
>>>
>>>
>>> I ran the testcase provided in the webrev and debugged a little.
>>> FOCUS_LOST
>>> does come to the textarea on its disposal, though when the
focus event is
>>> being dispatched I see the peer is null.
>>> This is quite expected actually. When Component.removeNotify()
is called
>>> on
>>> EDT, it transfers focus further (appropriate focus events get
queued) and
>>> then nullifies the peer. The events come later.
>>> Hope this helps.
>>
>> Thank you (I do not have Linux, so I can not debug this).
>> So, now we know that the cause of the problem is that our internal
>> AWTText(Field|Area) may be disposed while they think
>> that they are focused, and, at the same time, we can not propogate
>> real focus lost to them since peer is desposed
>> before we receive the event.
>> So, the suggested fix works fine for one particular problem
(unstopped
>> timer), but we may get some other
>> problems due to the cause.
>> For me it looks like better fix would be to pass synthetic focus
lost
>> when we dispose text peer, this way we guarantee
>> that life-circle of our synthetic components will be similar to real
>> ones and we will meet Swing's expectations.
>>
>> Does this sounds reasonable?
>>
>> Regards, Oleg.
>
>
> This sounds reasonable, though I personally don't like the idea
of yet
> another synthetic focus event...
well, (synthetic) focus events are your area of expertise ;)
> I actually like the fix Sean suggested (after we see the whole
picture).
> Otherwise, we may follow your suggestion
> to create AWTTextArea.removeNotify(). And even simpler, why not
to put
> getCaret().setVisible(false) right into
JTextComponent.removeNotify()?
well, the later is a question for Swing team.
The former is reasonable fix (not the best one, but good enough).
So, if everyone agree with this approach then I'm fine (hope this is
the only problem we
will have with invisible focused JTextXXX)
Oleg.
>
> Either of these looks fine to me.
>
> Thanks,
> Anton.
>
>
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou
