I've been writing a series of classic arcade games in Greenfoot (including "Breakout" and "Space Invaders") for my students to practice on in my AP course at the high school I teach at. To do so, I've been working on a variety of computers (Windows XP and Windows 7, primarily), utilizing originally Greenfoot 2.1.2 with Java 7 (Update 4) JDK. Recently I upgraded to Greenfoot 2.2.0. I'm coming across an odd "bug" in my work which I cannot determine the source of. In all games where I use the keyboard to control the movement of an object on the screen (paddle in Breakout, turret in Space Invaders), I typically put keyboard detection code in the act() method of the moving object itself. I've created a basic structure to use the Greenfoot.isKeyDown() method to determine if the left arrow or right arrow is being pressed, and if so, to move the actor appropriately on the screen. If I run this under the Greenfoot IDE (and, as it turns out, even in a compiled JAR file version), the game will periodically freeze up at random times, for random amounts of time. In Breakout the ball will cease motion, and it will appear that the game has stopped. In Space Invaders, every actor stops dead and quits moving. It's as though the act() methods of all actors quits being called (perhaps the World/Greenfoot stops sending act() calls to the objects?). However, in addition the GUI itself becomes nearly unresponsive; clicking on the "Pause" button will not work. If I view Windows Task Manager, the java.exe process reports nearly 0% process use. During these random "freezes", I've learned that I can press ALT+S to toggle open the "Scenario" menu at the top of the screen, and immediately press ALT to dismiss that menu, and this will restore operation to the active World process. This happens without fail when the freezes occur. If, instead, I click the "Reset" button, the GUI world space is cleared, but will not reset properly on its own. For instance, my current computer resolution is smaller than the size of the world I'm creating, so there are scrollbars to help scroll the game world. When this occurs, the world clears to a white rectangle of space and the scrollbars don't properly repaint, so it's as though the standard Windows/Java message queue process is being frozen. I can open the debugger panel and terminate the process, at which point again the GUI becomes responsive. To test a theory, I edited my code to allow the Breakout ball to rebound off all 4 walls of the screen, ran the scenario at full speed on the slider bar, and sat back. It never once froze, and at times pegged my process at 25% CPU. This leads me to believe there's something going on with the Java subsystem that is perhaps overloading the system due to the arrow keys being held down. I've noticed if I use the Greenfoot.getKey() method to "consume" keypresses as part of the isKeyDown handler code, that freeze ups occur less frequently, but they still occur. In most cases, when a longer freeze occurs, I can move the speed slider to maximum, not press an arrow key, and eventually the game will spontaneously continue on its own. Again, I'm not sure if this is somehow a case of thousands of "keyDown" messages are getting piled into a buffer, bogging down the Java/Windows system and by not pressing any keys and running the GUI at full speed will eventually clear those out. Has anyone else experienced this behavior? There are no while, do-while, or for structures in my code, so I'm doubting that there's anything causing an inadvertent infinite loop - and besides, I find it interesting that I can immediately get the GUI to become responsive and active by toggling a menu on the menu bar. As a programmer, that makes me think it's somehow related to the messaging queue or Windows in general, Java subsystem perhaps as well. I've only so far worked with the Java 7u4 JDK at this point, and I know Java 7 has had some significant issues. I wasn't sure if I could run Greenfoot 2.2 under a more stable Java 6 environment, but I'm beginning to consider rolling back all of my systems to Java 6. This constant, random freezing is making Greenfoot almost impossible for me to use in my school since it interferes with the design of full-motion games. Thanks for any info anyone has about this. I'm curious to know if it's only me, or if there's an issue I don't know about. Londovir