Yes, the Drive_Spin_In_Place_PID instances will remain in the heap until collected. This gets into an interesting area in using Java for FRC. Typically, at least I have not seen it, garbage collection is not an issue. I believe this is because we have lots of space and relatively short run duration (a match). We typically do not produce enough garbage that collection becomes an issue.
However, as I mentor students in Java programming, I want them to become good Java programmers, so I strongly encourage them to worry about it. I have seen sloppy object lifecycle management practices drive long running Java systems (days, weeks, months) into the ground.
In this particular case I think you could avoid the issue by getting rid of the x_Test_Lookup class and connecting a single Drive_Spin_In_Place_PID command instance directly to the button. Something like:
Code:
a_1 = new JoystickButton(xbox_1, 1);
a_1.whenPressed(new Drive_Spin_In_Place_PID(false));
Note that I took the first parameter off the constructor. You can move the calculation of that value from x_Test_Lookup#initialize() to Drive_Spin_In_Place_PID#initialize().
One other note on something I think I see but I have not run this so I could be off base. Since both commands require the driveTrain subsystem, the start of the Drive_Spin_In_Place_PID command will cause the x_Test_Lookup command to be interrupted. When it is interrupted, it stops executing and its interrupted() method is called, which in your code calls its own end() method (very common practice) which in turn calls end() on the current Drive_Spin_In_Place_PID instance. This will NOT cause the Drive_Spin_In_Place_PID instance to stop. It will continue until some terminating condition is met (isFinished returns true, it is interrupted, etc). So things work as you expect but perhaps not for the reasons you think.
I hope this helps,
Steve