How to judge which objects are eligible for garbage collection. This code extract has been taken from Johnathan Giles java note. The explantion given by him is confusing me. Here it is ....
Even when e3 and e2 are set to be null, it is
not possible to do any garbage collection,
even though it feels like it should be possible
to garbage collect e2.
This is because e2 is still accessible from e1,
indirectly. E1.e refers to the original e3, and
e3.e still refers to the original e2.
Therefore, no garbage collection is possible
until all three objects are set to null, and they
become an island of references ready for GC.
Campbell Ritchie wrote:The whole idea of using a high-level language is to avoid having to bother about such questions.
However if you do want such functionality .....
I suggest you use a static variable that is incremented over every Object creation.
Campbell Ritchie wrote:And I think you have the ++ operator in the wrong place, Janeice. And surely the second line belongs inside a constructor??
The ++ operator is in the correct place. I stand by that. Otherwise, the very first instance would be 0, not 1.
Although I suppose the second line could go in a constructor, if you are only using the default constructor, is it necessary?
I'll check out that book, too.
Better? I'm not really sure about this....
I think the problem with my class is the bar is set pretty low. They care that things compile and work correctly. No one talks about more advanced things. With some of the responses I've gotten from the graders, I bet not many people put much effort into their projects.
Janeice DelVecchio wrote:Better? I'm not really sure about this....
This is a threadsafe version of the class. You can't synchronize a constructor so instead a static creation method is introduced. The actual increment can alternatively be made in the private constructor. Many would prefer that for reasons of clarity.
Now objects can be created from any thread and you don't risk having two objects with the same number.
Janeice DelVecchio wrote:so when you make a widget, you do this?
No you use it like an ordinary static method like this,
Widget foo = Widget.next();
Note that a creation method usually is called "create" or has "create" in the name, so maybe "createNext" would've been a better choise.
Campbell Ritchie wrote: . . . or "getInstance()"
But "getInstance" suggests you're going to be getting an instance which already exists, as in a singleton class. If you look through the Java API documentation, there's a large number of methods named getInstance, but they are all (I think) static members of their classes. That's the static factory pattern. Methods which genuinely create a new instance tend to be called newInstance, and there's about 50 of those in the Java API. Some of those are static members, too, but quite a few are not.
There aren't any "createInstance" methods in the API, but there's a long list of "createThis" and "createThat". So a method which creates a Widget could be called "createWidget".
Really, the only difference is that the static method is not caring whether or not an instance already exists... it just makes one (and in our version counts the instances).
Thanks! I learn so much around here!