faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Java bindings
by Boudewijn Rempt on Tuesday 11/May/2004, @04:08
|
| Yes, I first used gij to verify it all worked, and then slowly worked up towards an optimized binary... Is there a special reason for the naming of the shared library? I just named it qtjava.so... |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Java bindings
by Richard Dale on Tuesday 11/May/2004, @04:53
|
You need to name the compiled qtjava.jar 'lib-org-kde-qt.so' so that gcj/gij can search for it when resolving 'import org.kde.qt.*' in your program. It just extends the idea of .jar files to include compiled .so libs. If the directory containing 'lib-org-kde-qt.so' is on your LD_LIBRARY_PATH, it is exactly equivalent to qtjava.jar being on your CLASSPATH.
If you name it qtjava.so you can only use the lib by naming it in a gcj compile command, and not as a qtjava.jar replacement as above.
|
[
Reply To This | View ]
|
Re: Java bindings
by Zoltan Bartko on Tuesday 11/May/2004, @10:04
|
Do I understand that well? Does it mean that I could actually develop my app faster in java with gij and when I would be satisifed with the result, just let it through gcj? Or is there something else to know about this?
Zoltan
|
[
Reply To This | View ]
|
Re: Java bindings
by Richard Dale on Tuesday 11/May/2004, @10:31
|
Yes, you can use both gij and gcj, but I've found nearly all QtJava and kde koala java apps run quite fast enough using gij. I think you'd only need to compile to native code with gcj if your app is graphics intensive. On the other hand, with Swing nearly all the code is java, and so it makes much more difference whether or not you have a jit compared with just ordinary slow interpreted code.
|
[
Reply To This | View ]
|
Re: Java bindings
by Boudewijn Rempt on Tuesday 11/May/2004, @11:27
|
Yes, that's what I set out to discover. I have a vague intuition that applications somehow find easier acceptance if they're native code, instead of any kind of bytecode. Richard is right, though, for the actual performance there's not much difference, perhaps because qtjava uses JNI, and Mark Wielaard tells me that for every JNI call, gij is called to generate some bytecode, which is then executed. Things could be faster, he tells me, but I think it's plenty fast enough. Although I noticed that putting a simple QMainWindow on screen is a lot faster with qtjava compiled to native code using -O2, than it is without optimization or in bytecode.
Also, I've checked Richard's other remark -- about the name of the shared library compiled from a jar -- and I was told that the difference is not that when the shared library has a name that doesn't reflect the package is contains, the java jar is used, but that when it's named qtjava.so (for instance), the ordinary dynamic linker is used, but when it's named org-kde-etc.so, the bootstrap classload is used; but in both cases it's native code.
Anyway, my next target is to find out how to create a library using java, compile it natively, and call that from C++. I think java is especially suited to appliation cores that handle data structures.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
