next »

[horati]

Well, if there's any parameter missing, that you need, we simply need to extend the signature.

That wasn't what I meant.  If you have classes C extends B extends A where A has an init() method intended for overriding so its constructor calls it, then a NullPointerException happens when C.init() accesses this.myCThing believing that it exists because C.<init>() initialized it.  These bugs tend to take a while to debug so the normal convention is that constructors are never allowed to call initXXX() methods.

[Marvin Fröhlich]

That wasn't what I meant.  If you have classes C extends B extends A where A has an init() method intended for overriding so its constructor calls it, then a NullPointerException happens when C.init() accesses this.myCThing believing that it exists because C.<init>() initialized it.  These bugs tend to take a while to debug so the normal convention is that constructors are never allowed to call initXXX() methods.

In this case, this should not be a problem. the init methods give you everything you need and should of course fill the scene appropriately. But even if the scene is not filled, there shouldn't be any nullpointer exception. Then the scene was just empty.

Marvin

[horati]

In this case, this should not be a problem. the init methods give you everything you need and should of course fill the scene appropriately. But even if the scene is not filled, there shouldn't be any nullpointer exception. Then the scene was just empty.

Yup, I agree that the framework should be fine.  I was referring to clients of the framework.  If there is anywhere in the framework where we have a constructor that calls an initXXX() method, it's probably a bad idea because we are making it easier for clients to create bugs for themselves... which ultimately produces support posts and discourages adoption because the framework gains the incorrect perception that it is difficult to use.

On a more interesting note, I just thought of an idea to eliminate the whole SWT threading issue rather than circumventing it the way that I did.  Not that thread synchronization between the renderer and SWT was huge overhead, but I think I can eliminate it by getting SWT canvas operations to execute inside the rendering thread.  I also hope this gets rid of the problems with the command line execution.  I'll keep you posted.

[horati]

Okay, I'm making some progress pushing the actual SWT object creation into the render thread for standalone usage.

Right now, I'm getting some messages from native code that I suspect you graphics programmer types might be able to help me with:

2007-02-14 12:29:12.115 java[21537] *** _NSAutoreleaseNoPool(): Object 0x3d97c0 of class NSCarbonWindowContentView autoreleased with no pool in place - just leaking
2007-02-14 12:29:20.958 java[21537] *** _NSAutoreleaseNoPool(): Object 0x3c9e00 of class NSCFArray autoreleased with no pool in place - just leaking
2007-02-14 12:29:20.958 java[21537] *** _NSAutoreleaseNoPool(): Object 0x3ebed0 of class NSCarbonWindow autoreleased with no pool in place - just leaking

I know I messed up somewhere.  Any ideas what API misuse caused this?

[Marvin Fröhlich]

Yup, I agree that the framework should be fine.  I was referring to clients of the framework.  If there is anywhere in the framework where we have a constructor that calls an initXXX() method, it's probably a bad idea because we are making it easier for clients to create bugs for themselves... which ultimately produces support posts and discourages adoption because the framework gains the incorrect perception that it is difficult to use.

Such a structure (contructor->initMethod) will never be used in the API itself. It is just used in the BaseTest, which should never be used by any client. It is solely meant to be used by other test cases.

On a more interesting note, I just thought of an idea to eliminate the whole SWT threading issue rather than circumventing it the way that I did.  Not that thread synchronization between the renderer and SWT was huge overhead, but I think I can eliminate it by getting SWT canvas operations to execute inside the rendering thread.  I also hope this gets rid of the problems with the command line execution.  I'll keep you posted.

Cool, if that will work. But I though, it already was this way. It just looks like, that SWT seems to need some things to be invoked from one of its own threads instead of the rendering thread.

I know I messed up somewhere.  Any ideas what API misuse caused this?

Sorry, I don't have any idea, what could cause this.

Marvin