How can we count the number of objects created per class using Java1.5 API?

[Jalli Venkat]

Hi,
How can we count the number of objects created for a class using Java1.5 API..?
Is there any such API available...?
If not means , what is the solution for this....?

[Paul Clapham]

public class LikeThis {
  private static int numberOfObjectsCreated = 0;

  public LikeThis() {
    numberOfObjectsCreated++;
    // other constructor business
  }

}

[fred rosenberger]

Note that while this will tell you how many have been CREATED, that does not tell you how many are currently ALIVE. You could easily write a for loop that creates 100 objects and immediately discards the reference, making them all eligible for garbage collection. And you have no way to know when that may happen.

[Campbell Ritchie]

The whole idea of using a high-level language is to avoid having to bother about such questions.

[Sidharth Pallai]

  Class Lost {
Lost e;
Public static void main(String[] a) {
Lost e1 = new Lost();
Lost e2 = new Lost();
Lost e3 = new Lost();
e3.e = e2;
e1.e = e3;
e2.e = e1;
e3 = null;
e2 = null;
e1 = null
}
}
  

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]

That is a question unrelated to the original thread. Please post that as a new thread; asking unrelated questions is called hi-jacking and can deprive the original poster of contact with their thread.

[salvin francis]

I agree with campbell on this:

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.

[Janeice DelVecchio]

I just had a question about this in my class. I think the cleanest answer is:

public class Widget {
     private static int numOfWidgets = ++numOfWidgets; // this increments every time a widget is made
     private int thisWidgetNum = numOfWidgets; // this assigns a number to the widget.. then you can find the live ones
// methods here include getters for the above class/instance members
} 

My $0.02,
Janeice

[Embla Tingeling]

Janeice DelVecchio wrote:I just had a question about this in my class. I think the cleanest answer is:

Is it thread safe?

[Janeice DelVecchio]

I know what thread safe means, but I don't know how to tell if something IS thread safe.............

[Campbell Ritchie]

Java Concurrency in Action, Janeice, by Brian Goetz and several other people. It's reviewed on our book reviews pages.

[Campbell Ritchie]

And I think you have the ++ operator in the wrong place, Janeice. And surely the second line belongs inside a constructor??

[Janeice DelVecchio]

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.

-Janeice

[Janeice DelVecchio]

So my guess is that it would be threadsafe if the two lines were inside a "synchronized" constructor:

public class Widget {   
     private static int numOfWidgets;   
     private int thisWidgetNum;
public synchronized Widget() {
     numOfWidgets = ++numOfWidgets;     // this increments every time a widget is made 
     this.thisWidgetNum = numOfWidgets;   // this assigns a number to the widget.. then you can find the live ones   
}
// methods here include getters for the above class/instance members   
}   
    

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.

[Embla Tingeling]

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.

public class Widget {      
    private static int numOfWidgets;      
    private int thisWidgetNum = ++numOfWidgets;   
    private Widget() {}
    public synchronized Widget next() { // static creation method
    	return new Widget(); 
    }
    // methods here include getters for the above class/instance members      
} 

Now objects can be created from any thread and you don't risk having two objects with the same number.

[Janeice DelVecchio]

so when you make a widget, you do this?

Widget foo = new Widget.next();    

?

[Embla Tingeling]

Janeice DelVecchio wrote:so when you make a widget, you do this?

Widget foo = new Widget.next();    

?

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]

. . . or "getInstance()"

[Paul Clapham]

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".

[Campbell Ritchie]

Point taken, Paul C.

[Janeice DelVecchio]

hmmmm..... this is so close to that Singleton pattern it's scary. I'm sad that I didn't see it sooner.

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!