The language spec only guarantees that the new object will be in a complete and consistent state after the constructor has finished.
When you add the key listener you pass a reference to you current object, so it's immediately possible for another class to call methods in your object, even though its constructor has not finished.
It's one of those theoretical warnings that rarely cause problems in practice, but the simplest way to keep safe in a case like this one is to finish creating the window and make it visible before adding any listeners.

ps I greatly preferred the first version. It shouldn't be the responsibility of a JPanel to create its own parent frame like in v2.
pps you don’t need all those supers when calling methods inherited from a superclass

so by first version you mean the first version i posted in this thread correct??, and if i take away the supers... Netbeans gives me the warning Over ridable method call in constructer....
,but by taking away the supers... my program does close now.

Another wierd thing is if i set my window visible in the controller class after creating window... instead of setting visible in window class, it wont close... even without the supers??

The "first version" is from your "I've changed this..." post - where you have one class for the game JPanel and another class (extends JFrame) for the main window, For me that's good design when each class represents one thing fully.

super. in constructors:
Netbeans is designed to support huge mission-critical projects and so warns of all kinds of code that, in theory, could cause bugs. Calling a method in a constructor, when the method could have been overridden and the override method assumed construction is complete can cause bugs. Will this happen in a one-person small project? Highly unlikely.
For now you can safely ignore that message - just keep your constructors small and simple, and be aware of what order things are being done in.

As for your other 3 issues - without seeiing the code there's nothing I can do.