• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

StackOverflowError when trying to use threads

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am currently working on a project that is basically a projectile motion simulation with a user interface.
The original version did not use any threads and simply took the data that was entered in by the user and performed the computations on that data in order to run the simulation.
Well the program would run incredibly slow and sometimes crash. After some research, I realized I had to use a new thread to handle the computations that was slowing down the program.

But now when I run the new version of the program, I get a StackOverflowError. I believe these sorts of errors have to do with infinitely running loops, and loops that are never exited?
But the while loop that I have has a condition that should exit itself.

Why am I getting this error, and how could I go about resolving the issue?

Here is the code:



And here are the errors that I am getting:

 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Its massively recursive ...

To create a SimulationGUI it must create a SimulationGUI which creates a SimulationGUI ..... > to infinity or you run out of stack RAM !

in ctr (example), you can't have a line like this it'll call itself to infinity , you probably meant to use 'this' but that's a bad idea as well ;-) ...




other problems (ignore these if your just playing) ...

You should really do as little as possible in the ctr, you really want your EDT variables to be final but don't register listeners in a ctr, have a create method and call it on the EDT.

In your run thread any interaction with the GUI you need to get onto the EDT thread see java SwingWorker, you shouldn't change the GUI on your thread.

 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok so I added a new method called createListeners() that will create the action listeners for the various text fields and buttons that I have.



And I call it in my SimulationGUI() constructor at the very end
I have also temporarily commented out the code that sets the text in my run method.
Here is the new error that I am getting:



Now in regards to not changing the GUI in my run() method.
Are you referring to where I set the text of my textfields?



Would I have to use a new thread for that? Or could I simply create a new method to set those text fields and call it in my run method.
 
Chris Hurst
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your creating a lot of simulation GUI's is that intended or should you just have one ? I suspect one is better, but then you'd need to determine the component initiating an action in the listener. To be honest looking at the code I'd recommend you do a few simple swing tutorials first, then come back to me for the threading.

These next two points are viild but I'd ignore them and sort out the issues above first ...

The reasons for doing the next two are complex so unless you really need to know I suggest you just do the following ..

1) You have a thread to set your text on already its the EDT (Event Dispatch Thread), lookup a tutorial on SwingUtilities invokeAndWait and InvokeLater your GUI updates should be driven this way.

2) As for construct then create, it should probably look more like this ..



 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok so basically, I need a SwingUtilities.invokeLater to update the text fields and I need a Swing Worker to handle the time consuming calculations in my program?
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Look at what you're doing in the constructor. For each GUI component that listens for events, you're creating a completely separate SimulationGUI object on which it listens, which is extremely wasteful. Furthermore, in the code

you call the constructor again. But then within that constructor-call this line is executed again and the constructor is called again. In this process of infinite recursion the run-time stack grows and grows until it overflows.

All the GUI components should probably listen for events from the same single SimulationGUI object. That is, in the original code that you posted, you should change


to

and similar for the other calls to addActionListener().

However, it is evident that you don't really get how the event handling of Swing works. First make sure that you really grasp what's going on in this code.
 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So I understand that my original code had infinite recursion. I've changed that part completely.
My action listeners are now (for example): button.addActionListener(this);
But my program still lags significantly and actually it become unresponsive, only running through one iteration of the loop I have in place, and I believe it's the time consuming calculations that I have going on in my code.

My original question is should I put the code that deals with the simulation inside a spring worker, since spring workers can handle time consuming activities, and put the code that updates the gui (the setting of the text) into a swing utilities invoke later, since that is a direct call to the EDT, and you said that any code that changes the GUI should be invoked on the EDT thread?
 
Bernhard Haeussermann
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Running a very time consuming operation in an event listener's code will make the GUI unresponsive. The GUI will not respond until the call to actionPerformed() (or whatever may be the case) returns. So, yes, using a spring worker should make the UI more responsive. I believe that's the type of situation that a spring worker is intended to handle.
 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because right now, I have a thread to handle the simulation code, but I guess it doesn't matter if the code is on its separate thread because it still is unresponsive.
So I will try using a spring worker for that. But how can you tell by looking at the code, whether something is going to be time consuming, because all I really have are calculations, nothing extra fancy.
However, I do ultimately want to draw a line that depicts the actual projectile. So maybe, I should just implement the code into a spring worker, so that when I do add in the animation, I won't have to worry about it.

See below:

 
Bernhard Haeussermann
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, I would suggest that you use a spring worker, so that you draw a line on the UI.

Initially, you can limit the number of iterations of the main loop to, say 100, and then plot the points to see what it looks like and continue from there.
 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The main loop meaning the while loop that I have? What do you mean limit the number of iterations to 100?
 
Bernhard Haeussermann
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I mean the loop with the condition (numBounces < 10).
I meant that you limit the number of iterations of this loop to say 100. You could do this by replacing

by

just to get a feel for what's going on.
 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But don't both conditions have to be true for the loop to exit ie. numBounces has to be less than 10 and i < 100
So the loop would still take the same amount of time?
 
Bernhard Haeussermann
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, if either condition becomes false the loop will exit.
 
Krysten Thomas
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
oh ok i see.

Thanks for the help
 
Did you ever grow anything in the garden of your mind? - Fred Rogers. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic