Thank you. The thing is that no one is giving an example of what "normal structure" is and why mine is "abnormal." I agree that the no comments thing is bad, but really I'd just be adding things like "//this is the paint method. It paints the screen" I don't know what NEEDS to be commented, as I was never very good at explaining my code.
"The paint method takes all the enemies and the player ship and paints them, as long as they are in active state (e.g. not killed). The paint method handles all the gamestates, so the code for the title screen, the boss fight and the pause as well as the gameover screen is also contained in here. The positions of the ships are _not_ updated here, but from the update() call in the main loop."
Another good candidate would be the collision method. This could at least contain the method of collision detection (AABB, OOBB, Sphere intersection). As a rule of thumb, just thow in some comments as soon as you don't do something obvious. You will be thankful, once you look at code older than a couple of month, trying to understand, what you were thinking.
Splitting your code into smallert parts is also a way to overcome this. If you have properly named classes (and base classes) and small methods doing one thing and are named like that, you can easily omit most comments, since your code would read like object oriented english text (to all our non-US/non-UK fellows: don't use your native language in class names and method calls!!!).
Some hints:
- Start classnames with a capital letter. Don't ask why, just do it.
(If you ask why, it's a distiction of classes and variables for the human readers of your source.
it also helps to identify the constructor of a class)
- You could also use accessors (getter/setter) for your fields and don't use public fields
(this one is debatable; I personally use public fields when I am _really_ sure
that the field will always have read/write semantics and I never would need a
"realtime" change notification. This is in my experience only true for final struct like
datasets/argument containers or temporal instances of private inner classes)
- Use separate files for classes
(You might prefer it in one file _now_, but trust us, you won't like it later)
- Find yourself a decent IDE and learn it's keyboard shourtcuts (especialy for goto type/class)
(This way, there is also no disadvantage anymore for having classes in separate files)
- Use javadoc comments - at least for classes
(Try to describe the purpose of the class in "human readable" form, like explaining it to your mother

)
Having said that, I don't find your code too bad, just more like a sketch or prototype instead of a game.
On performance:
- PROFILE, PROFILE, PROFILE!!!
Even if you need a week or two to make sense of a profiler, it is the most valuable tool you will have,
not only for performance improvement, but also for memory leak debugging (Yes, this will occur!)
- Try to create images/sprites/whatever possible beforehand and only paint them
- If you have to create things on the fly, try to cache them and successive only paint them
(only for objects that are expensive to create, don't cache Points and such!)
- For your blur, you combine 5 images into one, couldn't you just use 2?
- The last screen already including the accumulated screens from the frames before
- The new screen
- Eventually use spatial divisioning for collisions (but probably not be necessary for your amount of bullets/enemies,
but good to know anyway)
- divide your screen area into a grid (e.g. 16x16)
- make a collection for each grid cell
- on every ship update, remove the ship from the last collection ist was in
- after that put the ship instance into the collection representing the grid cell
it is now positioned in
- on collision detection, evaluate the cell, your bullet is in
- just check for collision with the ships in this cell
One last note:
Don't whine and call criticism bullshit only because we do not pamper you! 
Edit: This kind of shit is making me not want to open source anymore.
This is just childish. Have a job? You'll be surprised what kind of feedback you might get there...