Re: GCJ and C/C++ applications how is it possible ?
On Fri, May 24, 2002 at 10:25:34AM +0200, Pac wrote: | Le 23/05/02 à 22:09, dman a écrit: | dman On Thu, May 23, 2002 at 07:15:34PM +0200, Pac wrote: | dman | why ? | dman | dman Layers upon layers upon layers of indirection. The JVM interprets | dman java bytecode. It then delegates the native methods to some C code | dman (from the java-gnome project). Those C/C++ functions then invoke some | dman other C/C++ functions and so on. Each has overhead. Then you have | dman your callbacks. In Java callbacks are always wrapped in classes | dman (java is not OO, it is Class-O). When you pass a callback to the | dman java-gnome stuff it must do the necessary wrapping/unwrapping to | dman provide a C-level function pointer to the underlying GTK+ system and | dman marshall arguments back and forth. More overhead. The java-gnome | dman package must also keep track of all GTK+ widgets it creates so that | dman when the JVM's GC decides it is time to free it it can. That's more | dman overhead in storing references. | | this is the scenario when java-gnome is not nativly compiled isn't | it ? Java-gnome is always natively compiled. You can't non-natively compile C/C++ code :-). | With a native compilation which is possible with gcc, the | application should be faster. With gcj's native compilation of java you can manage to eliminate the overhead of the JVM's main loop and bytecode interpretation. You still have all the layers upon layers of indirection and overhead that was coded from the design of the system. | dman | the point is that evas provides hardware acceleration capabilities. | dman | dman Java and hardware acceleration don't mix real well. One of java's | | not exactly, for example see Gl4java which provides access to OpenGL | functions. I've tried a certain J3D app (OpenGL). It pegs my not-so-old CPU and sometimes kills the X server when exiting. I've also toyed with VPython (C++ python module providing 3D OpenGL widgets). It runs my CPU around 50-75% with an animation running. I don't remember the memory differences between the two system, and don't want to kill my X server to find out. | dman I've worked with java enough to know that you're not going to get | dman high-performance out of it. Swing is a dog. AWT it too limited. | dman Everything else is less mature and adds more layers of indirection. | dman On top of that, none of the JVMs I've used had really decent | dman (performance-wise) garbage collectors. I haven't tried Sun's jdk 1.4 | dman yet (is it even out of beta?) though. | | Maybe one way to tune java for high performance is a gui nativly | compiled. That may help part of it. Of course, native compilation is not a holy grail. People can write crappy C programs too. If you add enough layers of indirection and marshalling to achieve a native GUI you might even be worse off than just using swing. If you build the GUI directly in the JVM and can avoid many of the layers of indirection then it might help as well. For a better demonstration of the real problem with java's performance, compare javac and jikes. jikes is several orders of magnitude faster than javac and doesn't chew up nearly as much memory. Once I had to decompile a certain large library in order to tweak it a little, and then recompile it. The resultant source tree was ~15MB (no comments, no extra whitespace). Not only that, but the decompiler generated some identifiers that were legal UTF-8 encoded Unicode and totally valid in Java, but jikes couldn't handle it :-(. javac barfed with OutOfMemory exceptions (even though the system had plenty of memory left. Dumb design decision). gcj was way too slow and also barfed for some reason I don't remember (it also reported the same error many times). I managed to compile it by combining javac and 'find' in several passes. (I also learned about the MS-DOS/Windows limitations in command line length) | Sun jdk1.4.0 has been released but I've tried it and it appears to be | slower than the 1.3.1_03 for some program and take too much memory. | However Swing performances are much better says Sun's announcement... Supposedly reflection performance was greatly improved. Some benchmark showed Jython (on jdk1.4) as being faster than CPython. Jython on the other JDKs is much slower than CPython. -D -- Emacs is a nice operating system, it lacks a decent editor though GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpq2Vx5irKBJ.pgp Description: PGP signature
Re: GCJ and C/C++ applications how is it possible ?
On Thu, May 23, 2002 at 07:15:34PM +0200, Pac wrote: | why ? Layers upon layers upon layers of indirection. The JVM interprets java bytecode. It then delegates the native methods to some C code (from the java-gnome project). Those C/C++ functions then invoke some other C/C++ functions and so on. Each has overhead. Then you have your callbacks. In Java callbacks are always wrapped in classes (java is not OO, it is Class-O). When you pass a callback to the java-gnome stuff it must do the necessary wrapping/unwrapping to provide a C-level function pointer to the underlying GTK+ system and marshall arguments back and forth. More overhead. The java-gnome package must also keep track of all GTK+ widgets it creates so that when the JVM's GC decides it is time to free it it can. That's more overhead in storing references. | the point is that evas provides hardware acceleration capabilities. Java and hardware acceleration don't mix real well. One of java's design goals was to remove all system-level functionality from you. It goes so far as to provide only the lowest common denominator wrt system functionality. | But evas you should Xlib function create a window to put an evas | canvas into it. Ok. | I was wondering if a new GTK component were made to encapsulated the | Xlib call and be able to communicate with evas library. I don't know, you might be the first. In general there are two opposing styles of development : o high-performance o high-level (portable, maintainable, etc) They are opposing because high-level constructs have layers of indirection to provide the high-level-ness. High-performance stuff is naturally close to the hardware and the bits themselves and don't have the layers of indirection to get in the way of performance. In the right environment and non-extreme circumstances the two can be merged (after profiling!) to build a snappy application. I've worked with java enough to know that you're not going to get high-performance out of it. Swing is a dog. AWT it too limited. Everything else is less mature and adds more layers of indirection. On top of that, none of the JVMs I've used had really decent (performance-wise) garbage collectors. I haven't tried Sun's jdk 1.4 yet (is it even out of beta?) though. HTH, -D -- A man of many companions may come to ruin, but there is a friend that sticks closer than a brother. Proverbs 18:24 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpedrBWpL15l.pgp Description: PGP signature
Re: GCJ and C/C++ applications how is it possible ?
Le 23/05/02 à 22:09, dman a écrit: dman On Thu, May 23, 2002 at 07:15:34PM +0200, Pac wrote: dman | why ? dman dman Layers upon layers upon layers of indirection. The JVM interprets dman java bytecode. It then delegates the native methods to some C code dman (from the java-gnome project). Those C/C++ functions then invoke some dman other C/C++ functions and so on. Each has overhead. Then you have dman your callbacks. In Java callbacks are always wrapped in classes dman (java is not OO, it is Class-O). When you pass a callback to the dman java-gnome stuff it must do the necessary wrapping/unwrapping to dman provide a C-level function pointer to the underlying GTK+ system and dman marshall arguments back and forth. More overhead. The java-gnome dman package must also keep track of all GTK+ widgets it creates so that dman when the JVM's GC decides it is time to free it it can. That's more dman overhead in storing references. dman this is the scenario when java-gnome is not nativly compiled isn't it ? With a native compilation which is possible with gcc, the application should be faster. dman | the point is that evas provides hardware acceleration capabilities. dman dman Java and hardware acceleration don't mix real well. One of java's not exactly, for example see Gl4java which provides access to OpenGL functions. dman dman | But evas you should Xlib function create a window to put an evas dman | canvas into it. dman dman Ok. dman dman | I was wondering if a new GTK component were made to encapsulated the dman | Xlib call and be able to communicate with evas library. dman dman I've worked with java enough to know that you're not going to get dman high-performance out of it. Swing is a dog. AWT it too limited. dman Everything else is less mature and adds more layers of indirection. dman On top of that, none of the JVMs I've used had really decent dman (performance-wise) garbage collectors. I haven't tried Sun's jdk 1.4 dman yet (is it even out of beta?) though. Maybe one way to tune java for high performance is a gui nativly compiled. This is possible for example with SWT which seeems mature and provides the same functionality as Swing does. Sun jdk1.4.0 has been released but I've tried it and it appears to be slower than the 1.3.1_03 for some program and take too much memory. However Swing performances are much better says Sun's announcement... see you -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ and C/C++ applications how is it possible ?
dman escreveu: (java is not OO, it is Class-O). Have you got any URL explaining what you mean, or can you provide a concise explanation? -- _ / \ Leandro Guimarães Faria Corsetti Dutra+41 (21) 216 15 93 \ / http://homepage.mac.com./leandrod/fax +41 (21) 216 19 04 X http://tutoriald.sf.net./ Orange Communications CH / \ ASCII Ribbon Campaign against HTML email +41 (21) 216 15 93 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ and C/C++ applications how is it possible ?
On 2002.05.24 04:25 Pac wrote: Le 23/05/02 à 22:09, dman a écrit: dman On Thu, May 23, 2002 at 07:15:34PM +0200, Pac wrote: dman | why ? dman dman Layers upon layers upon layers of indirection. The JVM interprets dman java bytecode. It then delegates the native methods to some C code dman (from the java-gnome project). Those C/C++ functions then invoke some dman other C/C++ functions and so on. Each has overhead. Then you have dman your callbacks. In Java callbacks are always wrapped in classes dman (java is not OO, it is Class-O). When you pass a callback to the dman java-gnome stuff it must do the necessary wrapping/unwrapping to dman provide a C-level function pointer to the underlying GTK+ system and dman marshall arguments back and forth. More overhead. The java-gnome dman package must also keep track of all GTK+ widgets it creates so that dman when the JVM's GC decides it is time to free it it can. That's more dman overhead in storing references. dman this is the scenario when java-gnome is not nativly compiled isn't it ? With a native compilation which is possible with gcc, the application should be faster. I would love to be proven wrong, but far as I know, the main advantage of natively compiled Java, is that the java bits will run faster than their interpreted counterparts. You're still going to encounter the overhead of setting up the JNI stack and passing references back and forth. HTH, Ian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ and C/C++ applications how is it possible ?
On Wed, May 22, 2002 at 11:36:06PM +0200, Pac wrote: | | [...] | dman $ ./a.out | dman Hello World | | thanks but I all ready knew that !!! :-). | dman | dman | into a library and to use it into | dman | | dman | a GTK+ application | dman | a Qt application | dman | | dman | ?? | dman | dman To make use of existing C/C++ libraries requires writing JNI (or CNI) | dman bridge code in C/C++ to provide a Java interface that your Java code | dman can access. GCJ doesn't provide auto wrappers like that, it just | dman turns your java source into native binaries. | | I dont want to use a C/C++ library inside a java programm, I whave a | set java classes compiled into a native library (with compilation | option shared from gcj) and want to use this library into a Qt or GTK+ | application. Oh, I see. | Isnt it possible ? Anything is possible ... though the effort required varies :-). | See this from http://gcc.gnu.org/gcc-3.1/changes.html : | | # JNI and CNI invocation interfaces were implemented, so gcj-compiled Java code can now be called from a C/C++ application. I didn't know that. That's a good feature to have. I guess you'll have to RTFM the gcc docs to find out what that API is. Maybe it works just like compiling a C++ library except that you'll be missing the C++ header files (unless it can generate them too). | dman | dman For GTK+ you can take a look at http://java-gnome.sourceforge.net/. | | thank you | I will read this Does your GTK+ app already exist in C/C++? If not, then you can use java-gnome to write your app in Java and use the java libs directly. You also have the option of using jython and java-gnome together to write a non-distributed GTK+ app in python and still use java libs. Some of the interoperability options are rather interesting to consider. -D -- Q: What is the difference betwee open-source and commercial software? A: If you have a problem with commercial software you can call a phone number and they will tell you it might be solved in a future version. For open-source sofware there isn't a phone number to call, but you get the solution within a day. GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpUiIjkKqzxw.pgp Description: PGP signature
Re: GCJ and C/C++ applications how is it possible ?
Le 22/05/02 à 23:54, dman a écrit: dman dman | See this from http://gcc.gnu.org/gcc-3.1/changes.html : dman | dman | # JNI and CNI invocation interfaces were implemented, so gcj-compiled Java code can now be called from a C/C++ application. dman dman I didn't know that. That's a good feature to have. I guess you'll dman have to RTFM the gcc docs to find out what that API is. Maybe it dman works just like compiling a C++ library except that you'll be missing dman the C++ header files (unless it can generate them too). on http://gcc.gnu.org/java/docs.html there is no manual only a FAQ but I will read the different articles. dman | dman dman | dman For GTK+ you can take a look at http://java-gnome.sourceforge.net/. dman | dman | thank you dman | I will read this dman dman Does your GTK+ app already exist in C/C++? If not, then you can use no. dman java-gnome to write your app in Java and use the java libs directly. it seems to be a better idea I will probably take this way. By the way do you know if a GTK+ component has been made to encapsulate a minimal canvas tu use EVAS ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ and C/C++ applications how is it possible ?
On Thu, May 23, 2002 at 09:11:29AM +0200, Pac wrote: | Le 22/05/02 à 23:54, dman a écrit: | dman | See this from http://gcc.gnu.org/gcc-3.1/changes.html : | dman | | dman | # JNI and CNI invocation interfaces were implemented, so gcj-compiled Java code can now be called from a C/C++ application. | dman | dman I didn't know that. That's a good feature to have. I guess you'll | dman have to RTFM the gcc docs to find out what that API is. Maybe it | dman works just like compiling a C++ library except that you'll be missing | dman the C++ header files (unless it can generate them too). | | on http://gcc.gnu.org/java/docs.html there is no manual | only a FAQ but I will read the different articles. Read that part of the FAQ again (#6.2) : http://gcc.gnu.org/ml/java-patches/2001-q2/msg00224.html :-) | dman | dman For GTK+ you can take a look at http://java-gnome.sourceforge.net/. | dman | | dman | thank you | dman | I will read this | dman | dman Does your GTK+ app already exist in C/C++? If not, then you can use | | no. | | dman java-gnome to write your app in Java and use the java libs directly. | | it seems to be a better idea I will probably take this way. | By the way do you know if a GTK+ component has been made to | encapsulate a minimal canvas tu use EVAS ? I don't know what EVAS is, and I'm not sure if GTK+ itself has a canvas, but I know that GNOME has a canvas widget. -D -- Piracy is not a technological issue. It's a behavior issue. --Steve Jobs GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpGSgh8rCmsu.pgp Description: PGP signature
Re: GCJ and C/C++ applications how is it possible ?
On 2002.05.23 08:55 dman wrote: On Thu, May 23, 2002 at 09:11:29AM +0200, Pac wrote: | Le 22/05/02 à 23:54, dman a écrit: | dman | See this from http://gcc.gnu.org/gcc-3.1/changes.html : | dman | | dman | # JNI and CNI invocation interfaces were implemented, so gcj-compiled Java code can now be called from a C/C++ application. | dman | dman I didn't know that. That's a good feature to have. I guess you'll | dman have to RTFM the gcc docs to find out what that API is. Maybe it | dman works just like compiling a C++ library except that you'll be missing | dman the C++ header files (unless it can generate them too). | | on http://gcc.gnu.org/java/docs.html there is no manual | only a FAQ but I will read the different articles. Read that part of the FAQ again (#6.2) : http://gcc.gnu.org/ml/java-patches/2001-q2/msg00224.html :-) | dman | dman For GTK+ you can take a look at http://java-gnome.sourceforge.net/. | dman | | dman | thank you | dman | I will read this | dman | dman Does your GTK+ app already exist in C/C++? If not, then you can use | | no. | | dman java-gnome to write your app in Java and use the java libs directly. | | it seems to be a better idea I will probably take this way. | By the way do you know if a GTK+ component has been made to | encapsulate a minimal canvas tu use EVAS ? I don't know what EVAS is, and I'm not sure if GTK+ itself has a canvas, but I know that GNOME has a canvas widget. As does Java (java.awt.Canvas). BTW, you may encounter a performance hit when using Java-GNOME. I haven't actually tested it, but Java-GNOME uses JNI to communicate with C GTK+ widgets, so I would be surprised if performance is as good as using the GTK+ widgets directly. HTH, Ian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ and C/C++ applications how is it possible ?
why ? the point is that evas provides hardware acceleration capabilities. But evas you should Xlib function create a window to put an evas canvas into it. I was wondering if a new GTK component were made to encapsulated the Xlib call and be able to communicate with evas library. pac -- R.Pac -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GCJ and C/C++ applications how is it possible ?
On Wed, May 22, 2002 at 09:15:13PM +0200, Pac wrote:
| Hi all,
|
| does anyone have a documentation that shows how to use GCJ 3.1 to compile
| (in native mode) a set java classes
$ cat Hello.java EOF
public class Hello
{
public static void main( String[] argv )
{
System.out.println( Hello World ) ;
}
}
EOF
$ gcj-3.0 --main=Hello Hello.java
$ ./a.out
Hello World
$
| into a library and to use it into
|
| a GTK+ application
| a Qt application
|
| ??
To make use of existing C/C++ libraries requires writing JNI (or CNI)
bridge code in C/C++ to provide a Java interface that your Java code
can access. GCJ doesn't provide auto wrappers like that, it just
turns your java source into native binaries.
For GTK+ you can take a look at http://java-gnome.sourceforge.net/.
HTH,
-D
--
The remote desktop feature of Windows XP is really nice (and *novel*!).
As a Microsoft consultant can *remotely* disable the personal firewall
and control the system. We'll ignore the fact that this tampering with
the firewall is not logged, and more importantly, that the firewall
isn't restored when the clowns from Redmond are done with their job.
-- bugtraq
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
pgpK0MTtuxGym.pgp
Description: PGP signature
Re: GCJ and C/C++ applications how is it possible ?
[...] dman $ ./a.out dman Hello World thanks but I all ready knew that !!! dman dman | into a library and to use it into dman | dman | a GTK+ application dman | a Qt application dman | dman | ?? dman dman To make use of existing C/C++ libraries requires writing JNI (or CNI) dman bridge code in C/C++ to provide a Java interface that your Java code dman can access. GCJ doesn't provide auto wrappers like that, it just dman turns your java source into native binaries. I dont want to use a C/C++ library inside a java programm, I whave a set java classes compiled into a native library (with compilation option shared from gcj) and want to use this library into a Qt or GTK+ application. Isnt it possible ? See this from http://gcc.gnu.org/gcc-3.1/changes.html : # JNI and CNI invocation interfaces were implemented, so gcj-compiled Java code can now be called from a C/C++ application. dman dman For GTK+ you can take a look at http://java-gnome.sourceforge.net/. thank you I will read this -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
