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

Discussion in 'Java' started by KevinSimonson, Oct 18, 2010.

  1. 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
     
    KevinSimonson, Oct 18, 2010
    #1
    1. Advertising

  2. KevinSimonson

    projectmoon Guest

    Re: Does Code in a Separate Thread Have to be in a <run()> orCalled by a <run()>?

    On Mon, 18 Oct 2010 09:08:33 -0700, KevinSimonson wrote:

    > 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.
     
    projectmoon, Oct 18, 2010
    #2
    1. Advertising

  3. KevinSimonson

    markspace Guest

    Re: Does Code in a Separate Thread Have to be in a <run()> or Calledby a <run()>?

    On 10/18/2010 9:08 AM, KevinSimonson wrote:

    > 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.
     
    markspace, Oct 18, 2010
    #3
  4. Re: Does Code in a Separate Thread Have to be in a <run()> or Calledby a <run()>?

    On Oct 18, 10:17 am, projectmoon <> wrote:
    > On Mon, 18 Oct 2010 09:08:33 -0700, KevinSimonson wrote:
    > > 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.


    <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
     
    KevinSimonson, Oct 18, 2010
    #4
  5. KevinSimonson

    projectmoon Guest

    Re: Does Code in a Separate Thread Have to be in a <run()> orCalled by a <run()>?

    On Mon, 18 Oct 2010 10:07:15 -0700, KevinSimonson wrote:

    > <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.
     
    projectmoon, Oct 18, 2010
    #5
  6. KevinSimonson

    markspace Guest

    Re: Does Code in a Separate Thread Have to be in a <run()> or Calledby a <run()>?

    On 10/18/2010 10:07 AM, KevinSimonson wrote:
    > 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.
     
    markspace, Oct 18, 2010
    #6
  7. Re: Does Code in a Separate Thread Have to be in a <run()> or Calledby a <run()>?

    On Oct 18, 11:33 am, Peter Duniho <>
    wrote:
    > KevinSimonson wrote:
    > > [...] 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
     
    KevinSimonson, Oct 18, 2010
    #7
  8. Re: Does Code in a Separate Thread Have to be in a <run()> or Calledby a <run()>?

    On 18.10.2010 18:08, KevinSimonson wrote:
    > 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();
     
    Screamin Lord Byron, Oct 18, 2010
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. EvgueniB
    Replies:
    1
    Views:
    664
    Anthony Borla
    Dec 15, 2003
  2. Frank Fredstone
    Replies:
    1
    Views:
    463
    Jean-Francois Briere
    Jun 27, 2006
  3. Replies:
    0
    Views:
    553
  4. Anonieko
    Replies:
    1
    Views:
    609
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Feb 6, 2007
  5. ssylee
    Replies:
    2
    Views:
    746
    James Kanze
    Jan 28, 2008
Loading...

Share This Page