Static methods

[Shankara Sharma]

One of the restrictions that a static method has is It can only call other static methods and it can't call a non static method from it.

But When i create an object inside a static method, i can call a non static method. Here is the code below:

public class ClassB{
	
	public void display(){
		System.out.println(" Non Static method");
	}
		
	public static void display1(){
		System.out.println(" Static Method");
		ClassB classB=new ClassB();
		classB.display();		
	}
	
	public static void main(String[] args){
		display1();
	}
	
}

Can anyone please give an explanation?

[Edit - added code tags - see UseCodeTags for details]

[Riaan Nel]

Shankara Sharma wrote:One of the restrictions that a static method has is It can only call other static methods and it can't call a non static method from it.

But When i create an object inside a static method, i can call a non static method. Here is the code below:

public class ClassB{
	
	public void display(){
		System.out.println(" Non Static method");
	}
		
	public static void display1(){
		System.out.println(" Static Method");
		ClassB classB=new ClassB();
		classB.display();		
	}
	
	public static void main(String[] args){
		display1();
	}
	
}

Can anyone please give an explanation?

[Edit - added code tags - see UseCodeTags for details]

What the restriction implies is that there is no 'this' reference inside a static method that you can use to call instance methods. It's a completely different scenario if you create an instance of a class within a static method and call a method on the instance.

[Matthew Brown]

You can call a non-static method as long as you are calling it on an instance of the class.

If you're already in a non-static method, then you're already in an instance (the one referred to by this). Which is why you can call it directly. If you're in a static method there is no implicit instance, so you have to provide one. That's what you're doing when you call classB.display() - classB is a reference to a specific instance.

[Shankara Sharma]

We can even call a static method from non static method directly as static members part of the class.

Is that correct?

Another doubt regarding static members in a class:

Does static variables are loaded into memory even before an instance of that class is created?

Does memory is created for static methods and instance methods?

[Jeff Verdegan]

Please, don't put your entire questions in bold. It makes it annoying to read. Use bold and other font treatments sparingly and for emphasis only.

Shankara Sharma wrote:
We can even call a static method from non static method directly as static members part of the class.

Yes, we can call a static method from a non-static method.

Does static variables are loaded into memory even before an instance of that class is created?

Static variables are created when a class is loaded. They exist even if we never create an instance.

Does memory is created for static methods and instance methods?

It's not clear what you're asking here. Obviously methods use up memory. If they didn't, we could write a functioning program that had a size of zero bytes on disk and zero bytes in memory. Note, however, that there is only one copy of each method. Unlike non-static member variables, each instance does not get its own copy of non-static methods. There's no need for that, since methods' executable code is read-only.

[Shankara Sharma]

Creation of memory for static and non static methods in the sense, whether the memory is allocated before or after the instance creation?

[Jeff Verdegan]

Shankara Sharma wrote:Creation of memory for static and non static methods in the sense, whether the memory is allocated before or after the instance creation?

All the memory for all the method bodies' executable code is allocated once, when the class is loaded

[Shankara Sharma]

So for local variables inside methods when will memory be allocated?

Like whether memory allocation takes place when classes are loaded or when they are called?

[Matthew Brown]

You know, it really doesn't matter when the memory is allocated - you're fixating on that too much. But memory on the heap for objects will be allocated when the object is created, and memory for local variables will probably be allocated when they come into scope. I say "probably", because it's entirely up to the JVM how it manages things.

[Shankara Sharma]

Thanks to all you guys

[Jeff Verdegan]

Shankara Sharma wrote:So for local variables inside methods when will memory be allocated?

It's allocated on the stack when the method is entered.

[Dattatraya Tembare]

Yes, it's all about allocation of memory either in Heap or Stack.

When you create static members- variable or methods it goes in Heap only.
Second important thing is , it would not be a part of any instance , it allocates separate memory area in Heap.

When we create a Instance of a class it will create another memory area on heap.

And when we call a non-static method it’s part of Stack because each thread is having separate stack.
Now see there are two separate memory locations which are not linked together so we can’t access static variables/methods from non-static methods.

Non-static methods will be part of same object/memory location so it will allow to access.

Correct me if I'm wrong.

[Jeff Verdegan]

Dattatraya Tembare wrote:Yes, it's all about allocation of memory either in Heap or Stack.

No, the reason for not being able to access non-static variables in a static context has nothing to do with heap vs. stack.

And when we call a non-static method it’s part of Stack

The method's variables go on the stack. The executable code for method body itself, like all methods, is on the heap, as part of the class definition.

Now see there are two separate memory locations which are not linked together so we can’t access static variables/methods from non-static methods.

No, that's not right.

The reason we can't refer to non-static members in a static context has nothing to do with where variables are stored. There is no such concept of one area of memory not being able to see the other.

It's much simpler than that. Non-static members require a "this" reference to a "current" object. There is no "this" and no "current object" in a static context. That's simply a natural consequence of what "static" means in the language and it has nothing whatsoever to do with memory layout.

[Dattatraya Tembare]

Jeff Verdegan wrote:

Dattatraya Tembare wrote:Yes, it's all about allocation of memory either in Heap or Stack.

No, the reason for not being able to access non-static variables in a static context has nothing to do with heap vs. stack.

And when we call a non-static method it’s part of Stack

The method's variables go on the stack. The executable code for method body itself, like all methods, is on the heap, as part of the class definition.

Now see there are two separate memory locations which are not linked together so we can’t access static variables/methods from non-static methods.

No, that's not right.

The reason we can't refer to non-static members in a static context has nothing to do with where variables are stored. There is no such concept of one area of memory not being able to see the other.

It's much simpler than that. Non-static members require a "this" reference to a "current" object. There is no "this" and no "current object" in a static context. That's simply a natural consequence of what "static" means in the language and it has nothing whatsoever to do with memory layout.

Please explain me what is this here... this is object of existing class & it's on heap & static context is also on heap. So it's having access. When we call methos it creates copy on stack, we are having reference of object (this) so we are able to access the static data which is on Heap.

I think creating an object is all about allocation of memory, how can you separate this?

[Jeff Verdegan]

Dattatraya Tembare wrote:
Please explain me what is this here... this is object of existing class & it's on heap & static context is also on heap. So it's having access. When we call methos it creates copy on stack, we are having reference of object (this) so we are able to access the static data which is on Heap.

I have no idea what you're saying here.

I think creating an object is all about allocation of memory, how can you separate this?

Creating an object is partly about memory allocation. That has to happen, yes. But there's more to it than that.

This is not the point, however. You claimed that the reason that we can't access a non-static member from a static context has something to do with the stack and the heap not being able to see each other. That claim was incorrect, and I was merely pointing this out.

The rules about not accessing a non-static member from static context have nothing to do with what's on the heap and what's on the stack. That's the only point I was making.