The programmer's path almost sounds like the "way of the samurai". Another similarity is that once you start down this slippery road, you'll find it difficult to turn around. Actually, that's not difficult: The real problem is that you won't want to turn around. This lesson is about what you have to do to achieve your best life as a programmer.

If an object exists, it means that somebody needs it... In Java, this is how it works after an object is created, it exists (lives) as long as at least one variable is storing its address (there is at least one reference to it). If there are no more references, the object dies. The garbage collector comes for it and... Actually, everything isn't so tragic as it sounds. Quite the contrary.

If you don't save references to objects, the garbage collector will come for them at night to terminate them. As scary as this may sound, programmers are ready to pray to the Java garbage collector. Especially people who started their programming careers using other languages, such as C++.

Today our agenda includes a brief introduction to the most independent method: finalize(). It only obeys the Java machine in the sense that only the Java machine can call it. And it does so right before the object is destroyed. In fact, this method is the opposite of a constructor. It can free up the resources used by an object.

It's time to philosophize about the life and death of objects! Programmers often create dozens and dozens of objects and store them in various lists, but they never clean up these lists. This causes bloating. To avoid this, you have to use objects correctly. You'll get your first introduction in lesson.

In previous lessons, we found out that we can't call finalize using "handles". Only the Java virtual machine does this, and it's impossible to predict when it will do so. And what if you try to make it happen? For example, create 50,000 objects (cats and dogs, as usual)? We'd tackle this task and several more.

Let's dig into "static". Methods can be static and non-static. Ordinary methods are called on an object and have access to its data. Static methods don't have this access: They simply don't have an object reference. They are able to access a class's static variables and other static methods. The details are in the lesson.

Variables, methods, and even classes can be static. You'll learn what this is about and why you need it in higher levels, but for now you can look at the example and ponder what's going on here. We'll use a public static cast as a guinea pig. Sounds intriguing, doesn't it?

The topics we're raising here are laying solid groundwork for the future. It may not be entirely clear why everything is arranged this way, but it's already clear enough to practice doing tasks. We'll examine static methods as we create them in tasks. By the way, have you noticed that the main() method is also totally static?

The body of knowledge is growing, so the professor has to look ever more diligently for the information his students need. You won't get through this level without an extra set of additional reading. Still, the professor does his work well. The important thing is to not forget to take advantage of his research.

Hey, the sixth level is coming to its logical end! You've completed some difficult but useful tasks. Before you graduate and go to the seventh level, you should rest a bit and listen to a song about a programmer's hard lot in life. Here's a little dose of reality: "and so they code, and their brain corrode."

There's no such thing as extra tasks in the study of programming! The professor at the secret CodeGym center is 1000% convinced of this. That's why several tasks must be completed at the end of the level. Some of them are more advanced and require student's to be able to google. Or think. Or think and google.