Alexander Egger wrote: >>> 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. > If only finalize() would be reliable. Calling this method is up to the JVM and the statement "Called before the java object is removed by the garbage collector." is optimistic. It might be good enough on most JVMs, but I suspect to do it properly you have to stick with the explicit dispose(). > 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. > From the description so far I read that I will have to use finally blocks for everything that has a dispose() on it, which I suspect means most of Qt's classes. Failing to do so might result in resource leaks depending on the actual JVM used to run the application. > 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. > Swing might do the occasional System.gc() call or similar stunts. But it might also just be the fact that the Qt objects have a finalizer, which can hurt performance of the garbage collector in many ways, starting with the time the method needs itself. >> 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. > As said above: I would not rely on that, so I'd classify it in the same fashion as SWT. > 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. > That is the advantage of going native. It would be the main reason to switch for me. > 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. > More than a JButton with all its base classes? I can hardly imagine the API being that much worse :-)
Peter --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
