>> Great performance. Nice (native) looking. Great cross platform story. >> Easy to use. Sometimes strange if comes to garbage collection. Reading from the Jambi documentation:
protected final void finalize() Called before the java object is removed by the garbage collector. As the native resources belonging to an object may be cleaned up prior to the call of this function, it has been set as final. Reimplement disposed() instead, which will be called either as the native resources are being removed or just before the object is finalized, whichever happens first. public final void dispose() Explicitly removes the native resources held by the object. Note that though this method does not guarantee that the object will be garbage collected, it is not safe to reference the object after it has been disposed. As you can see from that. Jambi tries to keep a native object in sync with a java object. Sometimes things just go wrong and a reference is not there any more. But you have to program yourself into that. If you do not try to do something odd things are just fine. Another problem is that you never now when garbage collection hits so you app may freeze for while sometimes. We saw that problem because some students implemented the game in a way which created new objects for the game on every repaint which resulted in hundreds of thousands unreferenced objects. Oddly enough the performance of the game did not suffer a lot from that. Only once and a while the garbage collector came along and collected the objects resulting in a (very short) freeze of the game. Once we reused the objects things where fine and the garbage collector needed only to collect some objects which was not noticeable. For fun we reimplemented the "A lot of garbage objects" version using Swing. It actually performed very different than the Jambi version because the objects are collected more often in that version. From the results of the performance profiler it seamed that when using Swing the garbage collector collects the objects every x milliseconds so there was never the huge pile of objects which resulted in the freeze. Sadly we never investigated that further. And I never had a look on how Swing influences garbage collection. > That's the type of problem I could see in Jambi, too: in SWT you need to > manage all resources coming from the environment. That includes innocent > seeming things like color objects, which need to be disposed off > properly (i.e. in finally blocks) or you start leaking. I suspect Jambi > might suffer from the same problem. Seams that Jambi is easier here. In general the native resources are also disposed when an object gets garbage collected. btw.: Forgot another great thing about Jambi. Webkit, OpenGl and Phonon are build in giving you HTML rendering, 3D and multimedia support close to the underlying operating system. On the other hand: The huge number of methods in the interface of a simple button makes you wonder if the Qt design is somehow broken. Alexander --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
