• Post Reply Bookmark Topic Watch Topic
  • New Topic

where does the control of JVM goes after actionPerformed() method ?  RSS feed

 
naved momin
Ranch Hand
Posts: 692
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
consider a situation , where i have a GUI , in that GUI , i have a button , the implementation of that button's actionListener is in different class for eg

so if i click that button , my actionPerformed() method will get envoked in the ActionPerformedListener class ,
but my q's is where does the JVM's or Interpreters control goes after it reaches to the end of the actionPerformed() method ?
control goes at the last line of main() or in some Where else ?
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Control goes back to the method that invoked actionPerformed(). This is likely a method defined in another listener which is set by the component itself, such as KeyListener, MouseListener or something else still. If you click the button, the MouseListener will unwrap the MouseEvent, and then re-wrap the information as an ActionEvent and pass it to the actionPerformed() method. So who calls the mouseClicked() method? The Container object that holds the button does this in its own MouseListener. This goes all the way until you reach some native code that receives events through operating system interrupts and then puts them on the EventQueue.

All of this is just a wild guess on my part. If you want to figure it out, check out the source code that is bundled with the JDK.
 
Ralph Cook
Ranch Hand
Posts: 479
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm going to guess that the OP then wants to know where control goes after the listener is done.

Simple programs often have a main loop that is in the code the application programmer writes. It can be "enter a number to indicate your choice", then an action based on that number, and then loop back to the prompt for another choice.

UI systems (Swing, AWT) (OSX, XWindows, etc., etc.) are not like that - they are called event-driven systems, and they usually operate as a framework. In those, the application code sets up the environment (such as frames, controls, listeners, etc.) and then waits for the UI framework to call one of the components to indicate that something has happened that the application is set up to respond to. The fact that it is event-driven indicates that, in place of an application main loop, you instead have a system that listens for events and then executes the code the application has set up for those events. The fact that it's a framework means that, instead of your code calling it, it has a lot of code that calls your code.

So eventually, after actionPerformed and whatever listener called that actionPerformed routine, control is going back to the Swing framework to wait for another event to respond to. That code that gains control after the actionPerformed and the listener is not in your application, and certainly you can go look at the source if you would like, but it's pretty heavy reading.

rc
 
naved momin
Ranch Hand
Posts: 692
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ralph Cook wrote:I'm going to guess that the OP then wants to know where control goes after the listener is done.

Simple programs often have a main loop that is in the code the application programmer writes. It can be "enter a number to indicate your choice", then an action based on that number, and then loop back to the prompt for another choice.

UI systems (Swing, AWT) (OSX, XWindows, etc., etc.) are not like that - they are called event-driven systems, and they usually operate as a framework. In those, the application code sets up the environment (such as frames, controls, listeners, etc.) and then waits for the UI framework to call one of the components to indicate that something has happened that the application is set up to respond to. The fact that it is event-driven indicates that, in place of an application main loop, you instead have a system that listens for events and then executes the code the application has set up for those events. The fact that it's a framework means that, instead of your code calling it, it has a lot of code that calls your code.

So eventually, after actionPerformed and whatever listener called that actionPerformed routine, control is going back to the Swing framework to wait for another event to respond to. That code that gains control after the actionPerformed and the listener is not in your application, and certainly you can go look at the source if you would like, but it's pretty heavy reading.

rc

so all you want to say is that , the JVM controls goes back to some swing framework that is responsible for running my code again & again when my button hits up by someone
and the control isn't going to main() method ?
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, the control does not go back to the main() method. In fact, in most Swing GUI applications, the only thing the main() method does is show the GUI and then the main() method simply ends. So there isn't anything in the main() method to return control to.

When you display a Swing GUI, Swing will start up its Event Dispatch Thread. That's the main thread that waits for events like mouse clicks and that calls your event handlers whenever for example a button is clicked. When you've handled the button click, control goes back to the Event Dispatch Thread, which will then wait for the next mouse click or other input. Note that the Event Dispatch Thread is a separate thread from the thread in which the main() method runs.

When programming Swing applications, it's important to be aware of Swing's threading model. Your listeners and paint() methods are called on the Event Dispatch Thread. Your listeners and paint() methods should always return as quickly as possible. Don't do any long-running operations directly in a listener. If you do that, you'll lock the Event Dispatch Thread for the duration of the long-running operation, which means that the application cannot respond to user input - the application will appear frozen.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!