[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.platform] Re: Where is my JFrame? (was Strange behavior when trying to debug my application within eclipse)
|
Thakns again, it was very helpful
/Yaron
"Alexandros Karypidis" <akarypid@xxxxxxxx> wrote in message
news:4742CF72.30801@xxxxxxxxxxx
> Yaron Reinharts wrote:
>> Thank you Alexandros
>>
>> I don't see this thread in the debug window
>> I see other threads, there are all seems to be running (including one
>> which
>
> Yes, this is correct. You will see all threads there as "running", even
> though the thread may just be waiting in vain for something to occur.
>
> There is an "interrupt" button which will change the thread's state to
> susspended and show you where the thread instruction pointer is at, along
> with a stack trace of how it got there.
>
> In order to see meaningful names, call "setName()" on your threads to give
> them human-readable descriptions. Then you can know which thread is what.
>
>> is called AWT-Shutdown)
>> I'm using Eclipse Version 3.3.1
>>
>> Anyway, I found a workaround for my problem (skipping the console
>> reading)
>> However, I'm still curious to understand what happened and to know if I
>> should do something about it (bug report)
>
> In any case if you _require_ console input, I'm pretty sure you can have
> it and still work around this (as described in my previous post) by having
> the thread's run() method wait for the JFrame constructor to return and
> then access the console.
>
>> Thanks
>> /Yaron
>>
>> "Alexandros Karypidis" <akarypid@xxxxxxxx> wrote in message
>> news:47429F85.3040509@xxxxxxxxxxx
>>> If you debug your application, you'll see that if you interrupt the main
>>> thread you'll see it's within:
>>>
>>> WDesktopProperties.init() line: not available [native method]
>>> whereas the other thread is
>>>
>>> FileInputStream.readBytes(byte[], int, int) line: not available [native
>>> method]
>>> My guess is that the Swing library somehow accesses the console in
>>> WDesktopProperties.init() causing a deadlock. I'd use an object to wait
>>> for the frame to become visible before proceeding with console access:
>>>
>>> public void run() {
>>> synchronized (sync) {
>>> try {
>>> sync.wait();
>>> } catch (InterruptedException e) {
>>> return;
>>> }
>>> }
>>> // ...
>>>
>>> and
>>>
>>> private WhereIsMyJFrame() {
>>> // ...
>>> JFrame frame = new JFrame("WhereIsMyJFrame");
>>> synchronized (sync) {
>>> sync.notify();
>>> }
>>> System.out.println("main window created");
>>> frame.setVisible(true);
>>>
>>> Also, I'd guess that you could reproduce this thing outside of Eclipse
>>> if you ran your program from the command line and redirected your
>>> standard input and output.
>>