1

I'm developing a small space shooter game. It's a fun way to learn JAVA and I want to make sure I'm doing things correctly. This object (ship) is spawning other objects during runtime (lasers). (ship -> lasers).

I've implemented things this way:

  • Object Ship is drawn on the screen. When touch is detected it's creating new instances of the class Laser then it adds them to the static LinkedList lasers inside of the GameScreen class.
  • GameScreen object is in charge of drawing and updating all the lasers, ships, and effects on the screen.

Self explanatory. But now:

  • detectCollision() is called and all the lasers that are intersecting ship objects are getting deleted from the LinkedList lasers.
  • at the end of the game (user quits) I iterate through all the instances of the Laser class that are stored in GameScreen.lasers linked list and set all of them to null. When finished I also set the list to null.

Is this the correct way of releasing allocated memory?

Laser creation:

abstract class Ship {
if (canShoot()) {
    Laser laser = new Laser(new Rectangle(x, y, width, height)); // bounds
    GameScreen.playerLasers.add(laser);
}}

Laser disposal:

public class GameScreen {
private void dispose() {
    for (Laser laser : playerLasers) {
        laser.bounds = null;
        laser = null;
    }
    playerLasers = null;
}}

GameScreen class collisionDetection():

public class GameScreen {
    private void detectCollision() {
        ListIterator<Laser> itr = playerLasers.listIterator();
        while (itr.hasNext()){
            Laser laser = itr.next();
            if (laser.bounds.overlaps(ship.bounds)){
                ship.health -= laser.damage;
                laser.bounds = null;
                laser = null;
                itr.remove();
}}}}
J4Nk0
  • 13
  • 7
  • 1
    Even in compiled languages like C or C++ ... when your program really EXITS (as you said: user quits) you dont have to deallocate any memory. Because all memory that gets allocated for a specific process is freed up by the operating system when that process dies (unless we maybe take about very specific stuff such as shared memory sections or such). In other words: there is no cleanup when your program ends. And as written in many many books and tutorials: in java, when you do not create memory **leaks** accidentally, the GC does all the deallocation for you, thus zero need to it manually. – GhostCat Sep 04 '20 at 12:13
  • 3
    And note: yes some stone old java books recommend to assign null to things that are no longer needed, to explicitly tell the gc "this can go away". But this isnt necessary in any current day JVM. Wherever you "heard" about doing such things ... better get a more recent/current source of information. – GhostCat Sep 04 '20 at 12:16
  • Thank you very much. Yeah, I've read some old books :) – J4Nk0 Sep 04 '20 at 12:21
  • Inside your `dispose()` method, setting `laser = null` just changes local loop variable, and does nothing to the `playerLasers` list. – M. Prokhorov Sep 04 '20 at 12:49
  • Thank you I realized. That was funny :D – J4Nk0 Sep 04 '20 at 15:05

1 Answers1

4

It's not.

Java is a garbage collected system. You can't 'deallocate'. Setting stuff to null won't make things deallocate.

Java will automatically clean up whatever is needed and you don't need to do anything to make that happen. The only thing you need to worry about is programming logic. For example, in this case, you do need the itr.remove(); call - that's not about deallocating a Laser object, that's about removing the lasershot from the game logic. Thus, remove the null alloc lines, and you end up with:

if (laser.bounds.overlaps(ship.bounds)){
                ship.health -= laser.damage;
                itr.remove();
}
rzwitserloot
  • 85,357
  • 5
  • 51
  • 72
  • Then why this? [link](https://stackify.com/memory-leaks-java/). – J4Nk0 Sep 04 '20 at 15:08
  • @J4Nk0 that is extremely convoluted stuff you're not going to run into and doesn't apply to your situation at all. They're bending over backwards to create objects such that active code can still 'get to it'. If you remove a laser from that iterator, you can no longer get to it, and GC will take care of everything. – rzwitserloot Sep 04 '20 at 16:33
  • Thank you for the help! – J4Nk0 Sep 07 '20 at 20:35