Hi people, There's an exercise in Eckel's book that says
Prove that class loading takes place only once. Prove that loading may be caused by either the creation of the first instance of that class or by the access of a static member.
Assuming there's no need to demonstrate that static fields initialization occurs when the class loads, I came up with this:
I didn't prove that loading may be caused by the creation of the first instance since that is pretty obvious. Does my code prove those two issues ? Is there anybody having another solution or approach ?
Why is Ex622 instantiating itself when it's the class that's doing the testing?
Why not ? Ex622 is testing itself.
How is LoadingClass used?
LoadingClass is used here: System.out.println("LoadingClass is loaded now, and z=" + LoadingClass.z), by using its z field. So how can I test it in a single program run ? Well: by instantiating the Ex622 class twice, and observing that the "i" field is identical for both objects, which shows that the initializing part of "i" occured only once (it inits with a random value). So all I proved was that class loading doesn't occur at each instantiation of that class ? Aha. So I need two program units that use a same class ? Launch one unit, use that class and then put the unit on hold (by waiting for input for example) and then launching the second unit and comparing a static field from both units ?
George and Igor, in the beginner's forum we try to guide students by providing hints and asking questions instead of providing them with complete solutions. Can you please play along?
In the first test case you want to prove that instantiating a class any number of times results in loading the class only once, correct? Compare this with the flow of your program.
You run "java Ex622" at command prompt or in IDE
JVM loads class Ex622
JVM executes static method Ex622.main()
Your code accesses and prints the static field Ex622.i
Your code instantiates an Ex622 as a
Your code instantiates an Ex622 as b
Your code accesses and prints the static field Ex622.i via a reference
Your code accesses and prints the static field Ex622.i via b reference
Since the reference variable (a or b) is used only to determine on which class to access a static variable, steps 4, 7, and 8 are all equivalent and can be replaced by "Ex622.i" without difference. Because nothing happens between lines 7 and 8, the latter is redundant.
What you're left with is proving that the class is definitely loaded when you do all of the following: call a static method on it, access one of its static variables, and instantiate it twice. By using Ex622 to both run the tests and test the first proof, you cannot isolate instantiating the class. You also need a different method of verifying whether or not a class is loaded than accessing a static variable that's one of the conditions you're trying to test.
Joined: Feb 18, 2005
>George and Igor, in the beginner's forum we try to guide students by providing hints and asking questions instead of providing them with complete solutions. Can you please play along?
Sure. But I am a Java Newb. So I've tried to write correct answer.
I'll play along, I promise. :roll: [ February 21, 2005: Message edited by: George Bolyuba ]
Joined: Dec 01, 2004
Thank you David, George and Igor. David, in the light of your comments, please comment on George's and Igor's input.
Joined: Aug 07, 2003
Originally posted by John Bran: David, in the light of your comments, please comment on George's and Igor's input.
Igor's solution takes a step in the right direction by removing the static field access as part of the test to see whether a class has been loaded, it still uses the test executor class as the test class.
While George's solution does pull out the test classes into two classes so both tests can be executed separately in the same JVM run, they still use static fields to test loading. This may in fact have no effect, but I don't think you can prove it doesn't.
One recommendation I'd make is to try to shy away from using output to prove something like this. For one thing, it requires a human to know what output to expect and validate it on each run. Granted the output is pretty clear, the result could be made available programatically.
Static initializer blocks allow you to have code that is guaranteed to be executed exactly once when the class is loaded. Instead of having that code set a static field or cause another class to print something as a side effect of being constructed, make it do something more simple to another class.
I don't know if I can make it any less vague than that without simply telling you straight out with an example. There are several things you could do, but the key is to operate on some other class in a way that is verifiable by the test-execution class.
Joined: Feb 18, 2005
Originally posted by David Harkness: George and Igor, in the beginner's forum we try to guide students by providing hints and asking questions instead of providing them with complete solutions. Can you please play along?
I am very sorry David I got your point
kind regards Igor
Joined: Aug 07, 2003
No worries Igor and George -- you're new here so I'm just giving advice. Welcome to JavaRanch!
We find that people learn quicker and remember it better if they figure it out themselves with guidance. Getting a solution gets the homework done faster, but they won't learn or retain as much.
But don't let that stop you from working out your own solutions as practice and fun.