That's the one (or at least very similar) that I'm seeing for my own apps every now and then. But it doesn't really help. All the engine is doing, is to tell the GL driver to draw some geometry. Why this causes a crash deep inside of the GL pipeline under some circumstances is beyond me. Another problem is, that you can't be sure when this happen because there's no context. You don't know if this happens during normal operation (I've never ever experienced this on one of my own devices) or if it happens when the context is shutting down anyway (or doing some other wierd thing).

No, because a static method has no idea which objects are actually to compile. It can't access the actual references. In the TextureManager, this works because it's a singleton. But World or FrameBuffer aren't, so this is not possible.  It wouldn't help anything anyway, because static or not, the preloading/-warming has to happen in the render thread, which in case of the AWTGLRenderer is the AWT event dispatch thread. Hence the delayed operation. In this case, the actual build/compile/prewarm has to wait for the render thread to initialize the GL context (that would be indicated by the message that I asked for).
I'm not sure why it freezes though. It looks like a dead lock, because there are some sync operations between the threads going on, but if there's no "Waiting..."-message, I don't see why this should happen ATM. I need a test case to reproduce and debug this, I'm afraid. Can you provide me with something?

You can configure the logger in the Logger class. Just set the log level to something higher (like http://www.jpct.net/doc/com/threed/jpct/Logger.html#LL_ERRORS_AND_WARNINGS) and the messages should disappear. The compileAllObjects-method is still there, I've just renamed it so that it reflects better what it actually does. It's now called prewarmAllObject(<FrameBuffer>)

I'm sorry, but I've no idea. All that jPCT-AE does is to render into the GL context provided by the app. It doesn't do anything in terms of modifying this context or playing around with layers or such. Whatever goes wrong here, has to be a problem with your app's setup, not with jPCT-AE.

No, it's not dead. The download works fine for me: http://www.jpct.de/download/net/jpct-ae.zip

Then either your loading/conversion of the texture is wrong or your texture coordinates are. I tend to the former, because that's more likely to get broken in porting then some simple floats that should behave the same in both languages.

Yeah, but Primitives don't really have proper texture coordinates. That's the point of ExtendedPrimitives. I suggest to port that too to have something that helps to limit the possible problem sources.

Oh, you are using the AWTJPCTCanvas renderer!? I wasn't aware of that, I always thought you were using the "normal" GL renderer. In that case, it's pretty clear that the preWarm doesn't help. That's because with the  AWTJPCTCanvas renderer, your application and the rendering are running in two different threads and your application can't access the GL context hence it can't execute preWarm directly and just ignores the call. I would have to make sure to push the preWarm() into the rendering thread's pipeline and execute it from there. I'll look at it.