How to know how many objects are on the heap?

[Mahtab Alam]

a friend of mine asked ,as it was asked to him in an interview.
How to know , how many objects are on the heap or how many objects at a particular time in Java
I think somethng like as many new that many objects
factory methods that return an instance
objects created through autoboxing

If someone know

[Campbell Ritchie]

The reason there is no such technique is that it is something you do not need to know.

[Maneesh Godbole]

I have always held that companies which ask such kind of inane questions, are not worth working for.

[Lalit Mehra]

I don't think there is a standard way to know the number of objects on the heap.
Although you can check the used heap size using the Java VisualVM provided with the Java Package.

cheers

[Saif Asif]

There is a hack on how to achieve this, however I extremely denounce the use of this technique ( and if this technique was feasible and plausible ) , it might have already been included in the Java API. The trick is to override the java.lang.Object class. I read about it in this article quite some time ago Link . The feasibility of this technique is , of-course, open for discussion.

[Campbell Ritchie]

Saif Asif wrote:There is a hack on how to achieve this,. . .

And that hack says this

On other VMs it might reformat your harddrive, sell your credit card details or promote you to sales manager.

Promotion to sales manager is of course the worst possibility amongst those outcomes.

He did say it worked on JDK1.3.1; on newer JDKs, however, it is impossible to create classes in packages whose names begin with java, so that trick no longer works.

[Saif Asif]

Campbell Ritchie wrote: And that hack says this
On other VMs it might reformat your harddrive, sell your credit card details or promote you to sales manager.
Promotion to sales manager is of course the worst possibility amongst those outcomes.

heheheheh you got that right I hope a sales manager isn't reading this post

Campbell Ritchie wrote: on newer JDKs, however, it is impossible to create classes in packages whose names begin with java, so that trick no longer works.

I got some question about this thing , I dont understand this actually. You mean we cant create a package with the name of "java.lang" and have a class name as Object ?

Am asking because I never tried it before and I eventually tried making a class ( immediately after reading your reply ) as below and it seemed to compile fine.

package java.lang;

public class Object {
	
	public Object clone(){
		//My own implementation of clone
	}

}

Is this what you had mentioned ? I made it in eclipse Juno with JDK1.7 and it didnt give me any warning and error . Whats wrong over here ? :-\ (confused)

[Jeff Verdegan]

Saif Asif wrote:You mean we cant create a package with the name of "java.lang" and have a class name as Object ?

Am asking because I never tried it before and I eventually tried making a class ( immediately after reading your reply ) as below and it seemed to compile fine.

package java.lang;

public class Object {
	
	public Object clone(){
		//My own implementation of clone
	}

}

Is this what you had mentioned ? I made it in eclipse Juno with JDK1.7 and it didnt give me any warning and error . Whats wrong over here ? :-\ (confused)

My guess would be that it's not the compiler that stops you, but the class verification step of the classloader.

Some compilers might choose to disallow that (if the JLS doesn't prevent them from doing so), but even if they did, that would not be sufficient to enforce the rule, since anybody could generate the bytecode without using a Java compiler, or could manipulate other bytecode that did make it past the compilation step.

If this rule is in fact enforced, it would have to be at runtime, by the JVM.

Did you try actually running code that uses this Object class?

[Amit Ghorpade]

Jeff Verdegan wrote:

Saif Asif wrote: I made it in eclipse Juno with JDK1.7 and it didnt give me any warning and error . Whats wrong over here ? :-\ (confused)

My guess would be that it's not the compiler that stops you, but the class verification step of the classloader.

Well when I got this evil idea of writing my own version of the Object class, I simply killed the compiler
(With a evil laugh) Reported and evaluated as a bug for JDK 1.6.0 Looks like they fixed it in a later release although the status is unresolved.

[Saif Asif]

Jeff Verdegan wrote:

Saif Asif wrote:You mean we cant create a package with the name of "java.lang" and have a class name as Object ?

Am asking because I never tried it before and I eventually tried making a class ( immediately after reading your reply ) as below and it seemed to compile fine.

package java.lang;

public class Object {
	
	public Object clone(){
		//My own implementation of clone
	}

}

Is this what you had mentioned ? I made it in eclipse Juno with JDK1.7 and it didnt give me any warning and error . Whats wrong over here ? :-\ (confused)

My guess would be that it's not the compiler that stops you, but the class verification step of the classloader.

Some compilers might choose to disallow that (if the JLS doesn't prevent them from doing so), but even if they did, that would not be sufficient to enforce the rule, since anybody could generate the bytecode without using a Java compiler, or could manipulate other bytecode that did make it past the compilation step.

If this rule is in fact enforced, it would have to be at runtime, by the JVM.

Did you try actually running code that uses this Object class?

Well I came across a number of new experiences when trying to attempt to create my very own java.lang.Object class.

Scenario 1 (main method inside the object class)
code snippet I used

package java.lang;

public class Object {
	
	private static long numberOfObjectsOnHeap ;
	
	/**
	 * My implementation of the clone method
	 * Prevent all cloning !!
	 * @return null
	 */
	public Object clone() throws Exception{
		//Human cloning has been banned ! So return null
		return null; 
	}
	
	/**
	 * My own constructor
	 */
	public Object() {
		System.out.println( "Here" );
		numberOfObjectsOnHeap++;
	}

	/**
	 * Get the count
	 * @return long
	 */
	public static long getObjectsCountInJVM(){
		return numberOfObjectsOnHeap;
	}
	
	public String toString(){
		return "No String here";
	}
	
	public static void main(String[] args) {
		System.out.println( new Object().toString() ) ; //Expected "No string here" to get printed
	}

}

If we try to compile and run this code from Eclipse , it seems that Eclipse compiler will always go for the java.lang.Object class of the original JDK configured in the build path , it will NOT use our version of the java.lang.Object like this. ( we can however put our implementation of the java.lang.Object in a jdk and package it configure it to the JDK for the eclipse but I didnt try this yet. ) . To use my version of the java.lang.Object , I compiled and ran the code from command line and it seemed to 'compile' fine although when I tried to run it , it threw the following excpetion

Exception in thread "main" java.lang.NoClassDefFoundError: Object (wrong name: java/lang/Object)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: Object.  Program will exit.

Scenario 2 (main method in different class but in same package java.lang
Code snippets

package java.lang;
public class Object {
	/**
	 * My own constructor
	 */
	public Object() {
		System.out.println( "Here" );
	}
	
	public String toString(){
		return "Hhee";
	}
	
}

//The main method in different class file but same package
package java.lang;

public class ObjectTest {
	public static void main(String[] args) {
		new Object();
	}
}

This again compiled fine but threw the exception ( from inside eclipse and from command line as well )

Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang
	at java.lang.ClassLoader.preDefineClass(ClassLoader.java:649)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:785)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:480)

So its still a no , I could compile it but I couldn't and run it.

As for the bug

Amit wrote: Reported and evaluated as a bug for JDK 1.6.0 Looks like they fixed it in a later release although the status is unresolved.

I think the bug is kept unresolved still due to this runtime exception but its just my assumption since they clearly mention it to be related to javac component and not the java class loader or maybe I might be wrong someplace.