File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Two Questions: Why = null, and why actual variable not method?...

 
Robert Paris
Ranch Hand
Posts: 585
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have two questions:
1. When making an variable in a class, why do i sometimes see these two different options? Are they the same?
public Object obj;
public Object obj = null;
2. Is there a difference in performance between these two:

I know the benefits of using getNum() but I wanted to know performance-wise. And I also know that with this example there couldn't be much performance gain either way, but what if it were done 1,000,000 times?
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Concerning question number two...
One of the best answers can be found by writing a quick test program that does what you're proposing a million (or so) times. You can use System.currentTimeMillis() to keep track of the time. Let us know what you learn.
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Concerning question number 1:
The first statement just declares a variable of type Object. Now the class knows that every instance of this object has to have a field to hold that value. You might do this if you want to delay initializing the variable until you run your constructor for example. You must initialize the field either
- at declaration
- using an initializing block
- in your constructors. If you do this, the field must be initialized in EVERY constructor that you have.
The second statment declares a variable AND initializes it to some value, in this case null.
 
Dirk Schreckmann
Sheriff
Posts: 7023
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...but all instance variables that refer to objects are by default initialized to null if they are not explicitly initialized. So, yes they are the same.
 
Robert Paris
Ranch Hand
Posts: 585
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
wait a minute, so is Cindy right or Dirk? They seem like conflicting ideas to me. How about this:
1. Does the compiler see a diff? i.e. will it throw a warning/error for one and not the other?
2. Does the JVM see a diff?
Dirk seems to be saying that it is initialized to null in BOTH cases, but Cindy seems to say it's initialized in only one case. I know primitives are defaulted to a value (so int x; means x = 0), but does the same hold true for Objects?
And for the 2nd question, I want to know how it is in the VM, not just actual performance - sorry. Is there an actual difference in how the stack is allocated, the memory allocated, etc? And from this, performance-wise. Because i could do tests and it'll come out all even, but it could be just because I have a TON of memory on my computer and in lower memory environs it'd be better to use one over the other.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dirk's right. Cindy is thinking of special additional rules for blank final fields.
[ August 14, 2002: Message edited by: Jim Yingst ]
 
Greg Ostravich
Ranch Hand
Posts: 112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They're both right.
It depends on the context of an initialization.
If you don't initialize an object in a class it defaults to null. If you don't initialize an object in a static context the compiler will complain about it.
Java 2 Exam Cram describes the rules as 'Variables that are declared inside code blocks are uninitialized.'
Here's an example:

There's my $.02 -
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greg- it's not that it's a static context; it's that it's a local variable. Local variables must be definitely assigned sometime before they are read, unlike non-final fields. Cindy was specifically referring to fields, and I thought that's what Robert meant by "When making a variable in a class". But it's good to include the local variables as well, for clarity.
 
Robert Paris
Ranch Hand
Posts: 585
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone who answered. Jim is right, I just meant class fields. But it is good to get that contrast, and I had forgotten about final fields and how there the compiler will not handle default values.
Now this brings another question:
final Object obj;
Does the compiler not allow the above code because the default initialization happens during the static context of a class being loaded by the ClassLoader? In other words, the VM inits Objects not explicitly set to null, NOT the compiler. The compiler either leaves them alone or marks them as "set to global object default" (or smth like that)?
[ August 14, 2002: Message edited by: Robert Paris ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
final Object obj;
I'll assume you're still talking about fields, not local variables, and so this code snippet is understood to be inside a class definition, but not inside any method (or other local context).
This code is allowed by the compiler if the field obj is subsequently assigned in every constructor. (And if you've got a current-enough JDK, as I recall there were some bugs with this sort of thing in some older versions...)
Does the compiler not allow the above code because the default initialization happens during the static context of a class being loaded by the ClassLoader?
We're looking at a non-static field, so the static context of class loading doesn't really have anything to do with it. Each instance will have its own value of this field; there's no way to assign that value until an instanc eis constructed.
In other words, the VM inits Objects not explicitly set to null, NOT the compiler
The compiler is responsible for generating instructions that will assign legal values to fields before they can be used; the JVM is responsible for (a) verifying that the bytecodes do in fact assign values one way or another before attempting to use the fields, and (b) executing the code when called to.
Hope that helps...
[ August 15, 2002: Message edited by: Jim Yingst ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jim Yingst:
final Object obj;
This code is allowed by the compiler if the field obj is subsequently assigned in every constructor.

Either that or in an instance initializer:
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic