aspose file tools*
The moose likes Beginning Java and the fly likes Two Questions: Why = null, and why actual variable not method?... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Two Questions: Why = null, and why actual variable not method?..." Watch "Two Questions: Why = null, and why actual variable not method?..." New topic
Author

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

Robert Paris
Ranch Hand

Joined: Jul 28, 2002
Posts: 585
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

Joined: Dec 10, 2001
Posts: 7023
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.


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
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.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
...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

Joined: Jul 28, 2002
Posts: 585
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

Joined: Jan 30, 2000
Posts: 18671
Dirk's right. Cindy is thinking of special additional rules for blank final fields.
[ August 14, 2002: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Greg Ostravich
Ranch Hand

Joined: Jul 11, 2002
Posts: 112
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 -


Greg Ostravich - SCPJ2
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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

Joined: Jul 28, 2002
Posts: 585
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

Joined: Jan 30, 2000
Posts: 18671
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

Joined: Jul 11, 2001
Posts: 14112
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:


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Two Questions: Why = null, and why actual variable not method?...