This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes Proving that class loading takes place only once Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Proving that class loading takes place only once" Watch "Proving that class loading takes place only once" New topic
Author

Proving that class loading takes place only once

John Brown
Ranch Hand

Joined: Dec 01, 2004
Posts: 35
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 ?
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Why is Ex622 instantiating itself when it's the class that's doing the testing? How is LoadingClass used?

You have two things to test to ensure each causes the same thing to happen only once during an entire program run. How can you test this in a single program run?
Georgy Bolyuba
Ranch Hand

Joined: Feb 18, 2005
Posts: 162
How about this:


SCJP 1.4 (100%) Done.<br />SCJD (URLyBird 1.2.3 Started)
John Brown
Ranch Hand

Joined: Dec 01, 2004
Posts: 35
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 ?
Igor Stojanovic
Ranch Hand

Joined: Feb 18, 2005
Posts: 58
Maybe this can help you :





kind regards
Igor
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
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.
    Georgy Bolyuba
    Ranch Hand

    Joined: Feb 18, 2005
    Posts: 162
    >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 ]
    John Brown
    Ranch Hand

    Joined: Dec 01, 2004
    Posts: 35
    Thank you David, George and Igor.
    David, in the light of your comments, please comment on George's and Igor's input.
    David Harkness
    Ranch Hand

    Joined: Aug 07, 2003
    Posts: 1646
    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.
    Igor Stojanovic
    Ranch Hand

    Joined: Feb 18, 2005
    Posts: 58
    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
    David Harkness
    Ranch Hand

    Joined: Aug 07, 2003
    Posts: 1646
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Proving that class loading takes place only once
     
    Similar Threads
    public static final String
    Please explain O/P ...
    Inheritence question
    Initialization Process
    Little challenge