[davecom]

Will an instance variable return nullPointerExceptions if you try to execute methods on it before its constructor has finished executing?

[dogwood]

My basic understanding OOP would tell me that if a instance variable is not static then it cannot be returned/used until the class it resides in is initialized via the constructor.

But then I ma be totally wrong. Just learning myself.

[Kristoff]

Originally posted by davecom:
Will an instance variable return nullPointerExceptions if you try to execute methods on it before its constructor has finished executing?

Is that even possible?

How can you have a handle on an instance if the constructor hasn't return the instance!!!

Impossible.

Dogwood,
In Java, static variables are class variable which have a differenct scope than instance variables.

class variables are initialized when the class is loaded and can be manipulated via static initializers:

Code:

class Foo{
  //static (class) variable
  static String s_Bar;

  //static initializer (optional)
  {
      s_Bar = "WORD!";
  }

  //ctor
  public Foo(){
      //do instance initialization
      //things here
      System.out.println(s_Bar);
  }

  public static void main(String args[]){
     Foo f = new Foo();
  }
}

When run, this will print out "WORD!" in the middle of executing the constructor.

If you comment out the static initializer, it will print out null.

Back to the question:
I really don't see how you could have a handle on a class instance before the c-tor returns the handle....it's impossible!

Also, the wording of your post is a bit off.
Variables never return anything...only methods and c-tors do---but I think I got what you are trying to ask.

Perhaps showing some code of your problem will help us understand better?

[davecom]

Originally posted by Kristoff:


Is that even possible?

How can you have a handle on an instance if the constructor hasn't return the instance!!!

Impossible.

Thank you for replying, but you're wrong about the handle. Indeed I have a handle to an uninitialized class. My class, Center, creates a new instance of SpriteEngine in the constructor which takes a reference to the Center instance as a parameter. Then in SpriteEngine's constructor it calls a different method of Center's. Then a NullPointerException is thrown.

Please note all this happens before the termination of the constructor of Center. I guess I answered my own question though and I should try changing the code.

[Kristoff]

Originally posted by davecom:


Thank you for replying, but you're wrong about the handle. Indeed I have a handle to an uninitialized class. My class, Center, creates a new instance of SpriteEngine in the constructor which takes a reference to the Center instance as a parameter. Then in SpriteEngine's constructor it calls a different method of Center's. Then a NullPointerException is thrown.

Please note all this happens before the termination of the constructor of Center. I guess I answered my own question though and I should try changing the code.

I didn't realize that you were trying to pass this around inside your constructor.

Check out the factory pattern...I think it will help your design out.

[davecom]

Yeah it was bad design on my part. Thanks for the heads up Kristoff. Very off topic, but would anybody happen to know why the paintComponent method of my JPanel subclass only starts getting called after I resize the window it's in even though my animation thread calls repaint several times a second?

[Kristoff]

repaint() only adds the region to the dirty region list.....paint() is only called once all pending events are dispatched. Are you sure there aren't a never-ending thread of events generated in your animation thread? And, are you sure it isn't a buffering issue?

Code would help

[davecom]

Originally posted by Kristoff:
repaint() only adds the region to the dirty region list.....paint() is only called once all pending events are dispatched. Are you sure there aren't a never-ending thread of events generated in your animation thread? And, are you sure it isn't a buffering issue?

Code would help :D

What do you mean by events? I don't see what the paint method has to do with events. I'm sure of it not being a buffering issue though. The paintComponent method is simply not called until the window is resized. After the window is resized it IS called 5 times a second as expected.

The following loop does iterate properly before the resize:

public void run () {
Graphics g = buffer.getGraphics();
System.err.println("run called");
long t = System.currentTimeMillis(); //current time in milliseconds
while (Thread.currentThread() == ticker && !paused) {
updateAllSprites();
drawSprites(g);
repaint();
System.err.println("thread loop iterated");
try
{
t += delay;
ticker.sleep(Math.max(0, t - System.currentTimeMillis()));
}
catch (InterruptedException e)
{
break;
}
}
}

Here's the paintComponent method:

public void paintComponent(Graphics g){
//do drawing here
g.drawImage(buffer,0,0,null);
System.err.println("sprite engine's paintComponent method called");
}


Thanks again for the help, Kristoff, any ideas?

[Kristoff]

When I was mentioning the behavior of repaint(), I was just reminding you that if you are calling it in a handler, that it wont call paint until all events are handled....a common mistake...but obviously not the case here...which is why I asked for code

Now, are you saying that when the app(let) first launches, that it does not repaint, but when you re-size the window once, it will begin repaiting every five seconds?

If so, are you launching from the command line, or an MRJAppuilder bundle?

[davecom]

Originally posted by Kristoff:
When I was mentioning the behavior of repaint(), I was just reminding you that if you are calling it in a handler, that it wont call paint until all events are handled....a common mistake...but obviously not the case here...which is why I asked for code ;)

Now, are you saying that when the app(let) first launches, that it does not repaint, but when you re-size the window once, it will begin repaiting every five seconds?

Yes, exactly!

If so, are you launching from the command line, or an MRJAppuilder bundle?

I've tried launching both ways with the same result. I'm using CodeWarrior, so it automatically launches via the command line when you run from within the IDE.

[Kristoff]

You on 10.1.5? With the JDK updates?

I had a problem with similar things on 10.1.4.

[davecom]

Originally posted by Kristoff:
You on 10.1.5? With the JDK updates?

I had a problem with similar things on 10.1.4.

Yes, I'm on 10.1.5 with all the latest updates.

[Kristoff]

Ok...I noticed back in 10.1.4 that I had a similar problem occur.

My app would launch, and the JPanel would be displayed, but it wouldn't be packed correctly--despite calling pack() then show() explicitly. The controls were cramped in there, and the JPanel wasn't sized right...controls were hanging a bit over the edge.

I noticed this with Limewire too.

But, if I resized the window, it would repaint and look just fine.

I noticed that when I launched it from the command line, it would be ok, but if I launched it via jar launcher or an MRJAppbuilder bundle, it would exhibit the behavior.

I lived with it.

Good news, it doesn't happen in Jaguar

Perhaps it's a similar issue--some obscure JDK bug. Do any buckyball timer errors (some Java-carbon thing) show up in your console log?

Try posting to the java-dev list that apple maintains at lists.apple.com. Someone there might know the real culprit.

[davecom]

Okay, well thanks for all your help none the less.

[davecom]

Originally posted by Kristoff:

Good news, it doesn't happen in Jaguar :D

It still does for me. Just installed Jaguar and nothing has changed.

[Kristoff]

Hmmm....
Let me think on it a bit and run through some old code of mine.

[davecom]

Well the new version of CodeWarrior is out, so I'll install that and see if the problem was with the auto-code generated by its RAD builder. Any ideas on your end?

[Kristoff]

try calling validate() before you call repaint.

[davecom]

I'll try that. Metrowerks has emailed me that their engineering team will be sending me a patch for my problem soon anyway. Thanks for the help, David