• Post Reply Bookmark Topic Watch Topic
  • New Topic

What happens when static methods are invoked/static variables are referenced?  RSS feed

 
David Tan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Given the following class:
public class Test
{
public static int staticVar=5;
public static void staticMethod()
{
System.out.println("hello world");
}
public static void main(String[] args)
{
System.out.println("staticVar=" + staticVar);
staticMethod();
}
}
What does the JVM (and Classloader) do when the following statements are executed:
1) When the static variable is being called eg. System.out.println(staticVar)
2) When the static method is being invoked.
Does the JVM load the class and create an instance of the class, BEFORE accessing the static variables and invoking the static method?
 
Eddie Vanda
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi David
Classes are loaded onto the "heap" by the class loader from your directory or from a jar file or from somewhere!
When you "new" a class you make (instantiate) a further copy (instance)on the heap of all the non-static variables in the class and links to all the non-static methods in the class.
When your reference a static object you reference it in the base definition of the class as loaded. So the same static variables are visible in all instances of the class and they would all see the change in value at the same time.
The same applies to static methods, except that their variables are stored on individual stacks so they can behave differently to calls from different instances. You do not need to "new" a class to call its static objects but you do need to "new" a class to get a handle to call any of its non-static methods.
Static variables and methods can of course be called by any method in scope, including non-static ones.
Ed
 
David Tan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ed,
Thanks for the detailed reply to make the understanding easier.
Another question, I trust/believe that Java have a "hierarchy" of classloaders for loading system-specific and user-defined classes
e.g. system specific like java.io.InputStream etc etc
I am interested to know
1) how the hierarchy is like?
2) for classes specfied in the classpath, which part of the hierarchy will they appear?
3) is there a separate classloader for each level of hierarchy?
Thanks!
 
Eddie Vanda
Ranch Hand
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, know very little about class loaders. I think their priority would be implementation dependent.
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hy David,
Why do you believe in hierarchies of classloaders?
What do you mean with system-specific classes?
I cannot see a benefit in different classloaders or hierarchies.
If I compile a class, I don't want it to be a lower-class class, compared to upper-class sun.classes.
... a working class hero
 
David Tan
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stefan,
I am actually referring to my other question on "Class Loading" in which you have answered as well.
It was the reason why I believe there are some "precedence" in class loading, so that's why I post that question.
For system-specific classes, I am referring to those like java.io.* etc, which coincide with those sun.classes
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!