Does Code in a Separate Thread Have to be in a <run()> or Called by a <run()>?

[KevinSimonson]

I'm trying to figure out how LimeWire works in the Eclipse debugger.
In
particular, when you run LimeWire in Eclipse, a GUI comes up with a
text field
at the top with "Search..." grayed out inside it, and with a green
button
immediately to its right with the tool tip "Search P2P Network", and I
need to
figure out what happens when I press that button.

I found a series of code that goes like this:

InputStream istream = socket.getInputStream();
socket.setSoTimeout(10000);
ByteReader byteReader = new ByteReader(istream);
OutputStream os = socket.getOutputStream();
OutputStreamWriter osw = new OutputStreamWriter(os);
BufferedWriter out = new BufferedWriter(osw);
out.write(type + " " + handoffLink + " ");
out.write("\r\n");
out.flush();
String str = byteReader.readLine();

and if I put a breakpoint on the line with the <out.flush()> and
another one on
the line with the <byteReader.readLine()>, and let LimeWire run until
it hits
the first breakpoint, and then hit run to take it to the next
breakpoint, the
GUI comes up in between those two breakpoints.

So it looks pretty clear to me that the code that brings up the GUI
must be in
some other thread. Doesn't that have to be the case? I mean, all
that's
happening is a <flush()> call; _that_ can't be causing a GUI to come
up. On the
other hand, a <flush()> call, being an I/O call, might cause the
current thread
to block which would result in another thread starting to execute,
mightn't it?
I guess I don't see any other explanation for this behavior except
that the GUI
must be coming up in another thread.

Anyhow, I wrote a Java program that put code into each LimeWire source
file that
has a <run()> method a few lines of code that create a file that I can
associate
back with that source file, and then ran LimeWire in the debugger
until the GUI
came up. Only two such files showed up when the GUI showed up. I
stepped
through the execution of those two <run()> methods, all the way to the
end of
each <run()> method, and the GUI didn't come up. How is that
possible? If the
code that brings up the GUI is indeed in a separate thread, doesn't it
have to
be either _in_ a <run()> method, or in a method called directly or
indirectly by
a <run()> method in a class that implements <Runnable>?

I'm really confused by this, and if someone can give me some input on
how I can
track the creation of this GUI in the debugger, I'd really appreciate
it.

Kevin S

 

[projectmoon]

If the code that brings up the GUI is indeed in a separate thread,
doesn't it have to be either _in_ a <run()> method, or in a method
called directly or indirectly by a <run()> method in a class that
implements <Runnable>?

Multithreading in Java can be achieved in a number of different ways. The
most straightforward way is to implement Runnable. You can also extend
Thread (which is usually not recommended), or use the stuff in the
java.util.concurrent package. There are also other ways such as
java.util.Timer.

Swing GUIs will also automatically start a few of its own threads, like
the event dispatching thread.

 

[markspace]

I'm trying to figure out how LimeWire works in the Eclipse debugger.

Is there a reason for this? It looks like LimeWire is just an end-user
application, not an API. It's just a Swing app.

I realize the source code is available on their website, but it's just a
connection to a Gnutella server. I think you'd be better off trying to
work out the Gnutella protocol than worrying about what one Swing app
does with it.

That said, since LimeWire is a network program, it's very possible that
the gui is waiting for a response from the network when it starts up.
And it's very possible that it gets the response it's looking for when
your trace flushes its buffer out to the socket it's writing.

The most probable "start" of some Swing GUI code will look like this:

SwingUtilities.invokeLater( new Runnable() {
public void run() {
// GUI code here...
}
} );

There are also SwingTimers (unlikely imo) and SwingWoker (possible in
this case, since waiting on network code is a "long task").

Anyway, good luck, but I think you're a little insane. Just write your
own stuff, it'll be easier.

 

[KevinSimonson]

Multithreading in Java can be achieved in a number of different ways. The
most straightforward way is to implement Runnable. You can also extend
Thread (which is usually not recommended), or use the stuff in the
java.util.concurrent package. There are also other ways such as
java.util.Timer.

Swing GUIs will also automatically start a few of its own threads, like
the event dispatching thread.

<projectmoon>, thanks tremendously for this information. I found
classes that extended <Thread>, classes that import
<java.util.concurrent>, and classes that use <java.util.Timer> all in
the LimeWire source code. How would you suggest that I attempt to
track how the mentioned GUI gets called? I put breakpoints in each of
the classes that extend <Thread>. I suspect that the problem isn't
with a <Timer>, although I don't know for sure. So I'm focusing my
attention on classes that import <java.util.concurrent>. Can I
concentrate on classes that import
<java.util.concurrent.ThreadFactory>, or are there other elements of
<java.util.concurrent> that can be used to create threads as well?

Kevin S

 

[projectmoon]

<projectmoon>, thanks tremendously for this information. I found
classes that extended <Thread>, classes that import
<java.util.concurrent>, and classes that use <java.util.Timer> all in
the LimeWire source code. How would you suggest that I attempt to track
how the mentioned GUI gets called? I put breakpoints in each of the
classes that extend <Thread>. I suspect that the problem isn't with a
<Timer>, although I don't know for sure. So I'm focusing my attention
on classes that import <java.util.concurrent>. Can I concentrate on
classes that import
<java.util.concurrent.ThreadFactory>, or are there other elements of
<java.util.concurrent> that can be used to create threads as well?

Kevin S

For the stuff I do, I don't really require anything beyond Runnable and
Timer. Sometimes I've used thread pooling stuff found in
java.util.concurrent. For more information on how to isolate your code, I
would read the other two responses.

 

[markspace]

How would you suggest that I attempt to
track how the mentioned GUI gets called?

Start at the entry point. Look in the manifest for a Main-Class, and
start there.

 

[KevinSimonson]

[...] I suspect that the problem isn't
with a <Timer>, although I don't know for sure.  So I'm focusing my
attention on classes that import <java.util.concurrent>.  Can I
concentrate on classes that import

Can you be more specific about the "problem"?  Your original post seemed
to only be saying you're trying to understand how the code works, not
that there's a problem per se.

Well, by "problem" I meant that I can't seem to get the debugger to go
to the code that _actually creates_ the GUI in question. I need to go
that code and modify it so it does something different from what it
currently does.

Kevin S

 

[Screamin Lord Byron]

came up. Only two such files showed up when the GUI showed up. I
stepped
through the execution of those two <run()> methods, all the way to the
end of
each <run()> method, and the GUI didn't come up. How is that
possible?

You can't really rely on the order in which the threads will run. If
you're interested in the code that makes up the GUI, you should start
from the application entry point and work your way up. Don't use the
debugger until you reach the code of interest.

I was bored so I've downloaded the Limeware source. Obviously the app's
entry point is org.limewire.ui.swing.Main.main() method.

From there it loads org.limewire.ui.swing.GuiLoader through reflection
and instantiate it. If you follow the calls further, you'll eventually
get to this method in org.limewire.ui.swing.Initializer:

// Load the UI, system tray & notification handlers,
// and hide the splash screen & display the UI.
loadUI();