Here is a step-by-step tutorial on getting GCJ working on Mac OS X. It’s aimed at Java devs on OS X who probably don’t have any experience with configuring and building GCC.
Why in the hell do people want to use GCJ? I thought it’d give a big boost to my application so I tried it out. Hotspot kicked the crap out of GCJ without even blinking. So I gave up.
Because Sun’s Java interpretes source code on the fly, which is more dynamic and extensible (like Perl), but quite slow. GCJ compiles to highly optimized native code so it should run faster; and you can give your users an executable, instead of interprete source files
One reason among others: it’s for people who really concerns about the distribution restrictions of Sun JVM. .. but I’m not sure about the case of Apple JVM anyway.
All modern VMs have some sort of compilations. For instance, Sun’s HotSpot may takes time in first run, but since it’s dynamic, it can use many profiling info for better run-time optimization — which no static compiler can do.
interrepting source code? yeah, that’s good for a laugh. java never interpreted source code like Perl. And then this clown from rogers.com(god, why is it always Canadians) goes on to say that its more dynamic and extensible. Another meaningless statement in any context he’s trying to allude to.
This kid was probably trolling, but jizzles is right, more often than not a modern jvm from IBM or Sun will trounce gcj executables in performance, even if the memory requirements are a little lighter for gcj.
Static compilation only allows improvements at compile time instead of code that is compiled (and recompiled) when the program is run. In theory, this allows for much more flexibility when code is run to be re-optimized on the fly. This means it is possible to have code run faster under a dynamic compilation scheme vs. a standard one. In practice, Java code run with the HotSpot VM in most cases is still not as fast as hand-tuned C/assembly code, but is close and is sufficient for most things that do not have extreme performance requirements.
However, since the compilation phase happens over and over again for Java apps, there is a greater startup penalty compared with statically compiled applications (and a memory penalty for the Java VM). GCJ helps with this overhead a bit, but the implementation of the Java runtime is probably not optimal because code compiled with GCJ doesn’t run any faster than code running on a HotSpot VM. In most cases, it actually runs slower. In addition, the whole Java API is not implemented (for instance, Swing is missing so you can’t compile GUI apps.
That’s not to say GCJ is completely worthless. In fact, there’s a product for Windows (Excelsior JET) that does something similar to GCJ, often with good results. The best improvements are in app startup time and general GUI responsiveness, which may be important issues for end users. I think once Sun’s VM supports caching JIT compilations, this speed difference will deteriorate, but it’s still an interesting way to speed up Java applications.
Apple has only implemented the client VM on OS X. So if you’re running any performance intensive code, you’ll see that Java is really going to be dog slow. Just take a look at the Scimark numbers for Macs. They’re about one quarter the speed of equivalently clocked x86 machines.
So GCJ might make sense on OS X if you’re interested in performance. Its pretty much useless on other platforms.
The only thing ahead of time (AOT) compilers bring to Java is a decrease in startup time. Performance wise, there isn’t any real difference. Especially in the GUI.
Java’s GUI appears slow on some systems because of the way Swing is heavily layered and due to poor programming. AOT compilers don’t help much, if at all. IIRC, If you look at the benchmarks posted on the Excelsior JET homepage, you’ll notice that the JVM it’s being compared to is the client VM. Throw in the server VM, and you’ll start seeing rather different results.
i also found that the hotspot (1.4.1 when i did this work) jvm gave very good performance for numerical work compared to C. C was faster, but not by that much, and it certainly wasn’t worth the effort to hand code in C at that stage. the work was evolutionary machine learning algorithms …
secondpoint; the dynamic optimisation benefits server software, long-running software, served applications, j2ee, etc etc
i really wish sunw ould do a completely new UI toolkit for java… not the inter-tangled swing/awt mess.
This could be a great alternative for SWT apps. As they are (most of the time) more responsive than Swing apps, compiling with GCJ to achieve a smaller memory footprint and start up time would be a great benefit.
GJC can compile the Eclipse IDE with SWT. IBM is using Eclipse as the application platform for its new On Demand Workplace – which provides an integrated cross platform (Windows, Linux and Unix now, OSX later this year) rich client for Lotus Notes, Document Management and more.
It seems to me that given Sun’s stalling/refusal to IBM’s request to open source Java that IBM may increase its support for GJC/Classpath, to obtain a fully open Java implementation. In which case GJC would become an increasingly important technology.
yeah, I’ve thought the same thing. IBM could put a lot of power behind the GCJ/Classpath combination. Arguably, they could get more accomplished with that direction than with JCP.
* It includes technology that makes it easy to combine C++ and Java — CNI.
* The way gcj and gij interact to offer things like garbage collection and introspection can be very useful. It’s quite feasible to create a number crunching shared library in Java, compile with gcj and call it from an interpreted java app, or from an existing C++ app.
* It’s more mature, more complete and runs on more processors than Mono, and includes a more complete and better tested class library. Version numbers don’t tell the complete story.
* It’s very cool to create a natively compiled Qt or KDE application using Java:
Or they could try to do with JikesRVM what they are doing with Eclipse. They could try to make it THE free java VM. Being it writen in java, I think it would be much more easy and quick to expand to conform the whole java especs. I would really like to see that move.
The real promise of GCJ is to actually deliver on Sun’s promise of portability. How many platforms does Java 1.4.x currently run on? Not a whole hell of a lot when you think about it. I can think of Windows, Linux, Mac OS X, OS/2, and Solaris. I’m not sure how punctual HP and SGI are about releasing JREs for their OSes. Last I knew, FreeBSD’s native Java was stuck at 1.3.1 and it took them years to acheive even that.
The point is, Python and Perl kick Java’s ass when it comes to portability. They aren’t much slower in performance either…in fact, for some tasks I would venture to say that Perl may even be a little faster at times.
With that said…I wish GCJ and the Classpath project much luck.
They [Python and Perl] aren’t much slower in performance either…in fact, for some tasks I would venture to say that Perl may even be a little faster at times.
Guess that depends on what you’re doing. If you’re doing anything that requires serious computation, forget about Python and Perl. Java with the hotspot server VM does come close to native C speeds and sometimes exceeds it[1]. Perl and Python on the other hand are completely inadequate[2] for computationally intensive tasks.
That’s not to say that you should never use Perl or Python. Use the best tool for the job. It is arguable that Perl and Python are more portable on the systems you’ve listed but Java is portable elsewhere. Perl & Python on a Palm? On a phone?
Also, you’re not taking into account projects like Kaffe/SableVM/etc that have implemented an open sourced Java -like VM that runs on many *nix platforms.
Ever since Panther came out, JEdit crashes a lot on OS X Panther. It seems to be something to do with the JVM that ships with Panther. So would it be possible to compile JEdit using this and run it without going through the OS X JVM to avoid the crashing problems?
“Or they could try to do with JikesRVM what they are doing with Eclipse. They could try to make it THE free java VM. Being it writen in java, I think it would be much more easy and quick to expand to conform the whole java especs. I would really like to see that move.
I didn’t say they didn’t have a right to do it. I asked why. As for me this is a public forum for people to express their opion as I did mine so “not interested?. just leave this topic” Posts like this are a waste of space. I expected an explanation from someone, not this sort of unintelligent drivel.
“I didn’t say they didn’t have a right to do it. I asked why.”
the reason is simply because they want to improve gcj on the mac os x platform. some of us want a free and open implementation. we will have it in the form of gcj. reason enough for anybody
Ever since Panther came out, JEdit crashes a lot on OS X Panther. It seems to be something to do with the JVM that ships with Panther. So would it be possible to compile JEdit using this and run it without going through the OS X JVM to avoid the crashing problems?
Not easily, I don’t think. Depends on whether JEdit uses AWT or Swing (though I’m pretty sure it uses Swing).
AWT works out-of-the-box with GCJ on GNU/Linux (it’s not *totally* complete, but it works) and requires that you have GTK+ installed. On Mac OS X, besides needing GTK+ installed, getting AWT to work is a little tricky right now. This post:
Apple’s Java implementation is quite nice. However, some apps can still benefit from native compiles via gcj. Also, each project is unique (as are each client/customer). So, if gcj can compile to native successfully and work correctly, it could be a huge benefit to some developers.
As I mentioned earlier, the combination of SWT and native via gcj could be really relevant for decreasing memory footprint and startup time, even if the overall app did not function faster after startup. I’m looking forward to testing this out with SWT this weekend.
I’ve experienced no such problems with JEdit under Panther. Try playing with the settings (especially text rendering) as JEdit supports some options that might jeopardize stability.
I am not the only one either, I did a search on the jedit community forums and there are lots of people having these issues. I’ll look at text rendering and see if that helps any.
Why in the hell do people want to use GCJ? I thought it’d give a big boost to my application so I tried it out. Hotspot kicked the crap out of GCJ without even blinking. So I gave up.
Poof.
Because Sun’s Java interpretes source code on the fly, which is more dynamic and extensible (like Perl), but quite slow. GCJ compiles to highly optimized native code so it should run faster; and you can give your users an executable, instead of interprete source files
One reason among others: it’s for people who really concerns about the distribution restrictions of Sun JVM. .. but I’m not sure about the case of Apple JVM anyway.
That’s not totally true.
All modern VMs have some sort of compilations. For instance, Sun’s HotSpot may takes time in first run, but since it’s dynamic, it can use many profiling info for better run-time optimization — which no static compiler can do.
That’s it.
WRT static compilers not
being able to optimized.
This is a claim that
people keep making,
but I have not seen
a conclusive proof for it.
Care to give some details?
interrepting source code? yeah, that’s good for a laugh. java never interpreted source code like Perl. And then this clown from rogers.com(god, why is it always Canadians) goes on to say that its more dynamic and extensible. Another meaningless statement in any context he’s trying to allude to.
This kid was probably trolling, but jizzles is right, more often than not a modern jvm from IBM or Sun will trounce gcj executables in performance, even if the memory requirements are a little lighter for gcj.
Well, Apple JVM is already bundled with OS X, so deployment of Java applications on Mac is a no-brainer.
Concerning performance, for most applications HotSpot is more than sufficient. It has been “quite slow” 2 years ago, but not anymore.
Static compilation only allows improvements at compile time instead of code that is compiled (and recompiled) when the program is run. In theory, this allows for much more flexibility when code is run to be re-optimized on the fly. This means it is possible to have code run faster under a dynamic compilation scheme vs. a standard one. In practice, Java code run with the HotSpot VM in most cases is still not as fast as hand-tuned C/assembly code, but is close and is sufficient for most things that do not have extreme performance requirements.
However, since the compilation phase happens over and over again for Java apps, there is a greater startup penalty compared with statically compiled applications (and a memory penalty for the Java VM). GCJ helps with this overhead a bit, but the implementation of the Java runtime is probably not optimal because code compiled with GCJ doesn’t run any faster than code running on a HotSpot VM. In most cases, it actually runs slower. In addition, the whole Java API is not implemented (for instance, Swing is missing so you can’t compile GUI apps.
That’s not to say GCJ is completely worthless. In fact, there’s a product for Windows (Excelsior JET) that does something similar to GCJ, often with good results. The best improvements are in app startup time and general GUI responsiveness, which may be important issues for end users. I think once Sun’s VM supports caching JIT compilations, this speed difference will deteriorate, but it’s still an interesting way to speed up Java applications.
“you can give your users an executable, instead of interprete source files”
Joke of the day!
Apple has only implemented the client VM on OS X. So if you’re running any performance intensive code, you’ll see that Java is really going to be dog slow. Just take a look at the Scimark numbers for Macs. They’re about one quarter the speed of equivalently clocked x86 machines.
So GCJ might make sense on OS X if you’re interested in performance. Its pretty much useless on other platforms.
The only thing ahead of time (AOT) compilers bring to Java is a decrease in startup time. Performance wise, there isn’t any real difference. Especially in the GUI.
Java’s GUI appears slow on some systems because of the way Swing is heavily layered and due to poor programming. AOT compilers don’t help much, if at all. IIRC, If you look at the benchmarks posted on the Excelsior JET homepage, you’ll notice that the JVM it’s being compared to is the client VM. Throw in the server VM, and you’ll start seeing rather different results.
i also found that the hotspot (1.4.1 when i did this work) jvm gave very good performance for numerical work compared to C. C was faster, but not by that much, and it certainly wasn’t worth the effort to hand code in C at that stage. the work was evolutionary machine learning algorithms …
secondpoint; the dynamic optimisation benefits server software, long-running software, served applications, j2ee, etc etc
i really wish sunw ould do a completely new UI toolkit for java… not the inter-tangled swing/awt mess.
t
The only thing static compilers are good for is memory footprint.
The only thing static compilers are good for is memory footprint.
That’s not really true. Looking at the benchmarks done by Excelsior at http://www.excelsior-usa.com/jetbenchswingmem.html you see that the memory consumption isn’t reduced by much.
This could be a great alternative for SWT apps. As they are (most of the time) more responsive than Swing apps, compiling with GCJ to achieve a smaller memory footprint and start up time would be a great benefit.
This is a very useful resource.
GJC can compile the Eclipse IDE with SWT. IBM is using Eclipse as the application platform for its new On Demand Workplace – which provides an integrated cross platform (Windows, Linux and Unix now, OSX later this year) rich client for Lotus Notes, Document Management and more.
It seems to me that given Sun’s stalling/refusal to IBM’s request to open source Java that IBM may increase its support for GJC/Classpath, to obtain a fully open Java implementation. In which case GJC would become an increasingly important technology.
yeah, I’ve thought the same thing. IBM could put a lot of power behind the GCJ/Classpath combination. Arguably, they could get more accomplished with that direction than with JCP.
You should use GCJ because:
* It is free — while Sun’s Java is not free.
* It includes technology that makes it easy to combine C++ and Java — CNI.
* The way gcj and gij interact to offer things like garbage collection and introspection can be very useful. It’s quite feasible to create a number crunching shared library in Java, compile with gcj and call it from an interpreted java app, or from an existing C++ app.
* It’s more mature, more complete and runs on more processors than Mono, and includes a more complete and better tested class library. Version numbers don’t tell the complete story.
* It’s very cool to create a natively compiled Qt or KDE application using Java:
http://www.valdyas.org/fading/index.cgi/hacking/gcj.html?seemore=y
Or they could try to do with JikesRVM what they are doing with Eclipse. They could try to make it THE free java VM. Being it writen in java, I think it would be much more easy and quick to expand to conform the whole java especs. I would really like to see that move.
The real promise of GCJ is to actually deliver on Sun’s promise of portability. How many platforms does Java 1.4.x currently run on? Not a whole hell of a lot when you think about it. I can think of Windows, Linux, Mac OS X, OS/2, and Solaris. I’m not sure how punctual HP and SGI are about releasing JREs for their OSes. Last I knew, FreeBSD’s native Java was stuck at 1.3.1 and it took them years to acheive even that.
The point is, Python and Perl kick Java’s ass when it comes to portability. They aren’t much slower in performance either…in fact, for some tasks I would venture to say that Perl may even be a little faster at times.
With that said…I wish GCJ and the Classpath project much luck.
They [Python and Perl] aren’t much slower in performance either…in fact, for some tasks I would venture to say that Perl may even be a little faster at times.
Guess that depends on what you’re doing. If you’re doing anything that requires serious computation, forget about Python and Perl. Java with the hotspot server VM does come close to native C speeds and sometimes exceeds it[1]. Perl and Python on the other hand are completely inadequate[2] for computationally intensive tasks.
That’s not to say that you should never use Perl or Python. Use the best tool for the job. It is arguable that Perl and Python are more portable on the systems you’ve listed but Java is portable elsewhere. Perl & Python on a Palm? On a phone?
Also, you’re not taking into account projects like Kaffe/SableVM/etc that have implemented an open sourced Java -like VM that runs on many *nix platforms.
[1]http://www.aceshardware.com/read.jsp?id=153
[2]http://www.tempest-sw.com/benchmark/
Macintosh already has a well implemented Java Development Environment. GCJ has no advantage.
I Updated the article giving a couple options for getting a faster build-time.
Ever since Panther came out, JEdit crashes a lot on OS X Panther. It seems to be something to do with the JVM that ships with Panther. So would it be possible to compile JEdit using this and run it without going through the OS X JVM to avoid the crashing problems?
“Or they could try to do with JikesRVM what they are doing with Eclipse. They could try to make it THE free java VM. Being it writen in java, I think it would be much more easy and quick to expand to conform the whole java especs. I would really like to see that move.
”
deals with SUN not to do that. wont happen
“Why
By z1xq (IP: 205.204.242.—) – Posted on 2004-05-21 15:08:28
Macintosh already has a well implemented Java Development Environment. GCJ has no advantage.
”
gcj developers dont think so. not interested?. just leave this topic
I didn’t say they didn’t have a right to do it. I asked why. As for me this is a public forum for people to express their opion as I did mine so “not interested?. just leave this topic” Posts like this are a waste of space. I expected an explanation from someone, not this sort of unintelligent drivel.
“I didn’t say they didn’t have a right to do it. I asked why.”
the reason is simply because they want to improve gcj on the mac os x platform. some of us want a free and open implementation. we will have it in the form of gcj. reason enough for anybody
Ever since Panther came out, JEdit crashes a lot on OS X Panther. It seems to be something to do with the JVM that ships with Panther. So would it be possible to compile JEdit using this and run it without going through the OS X JVM to avoid the crashing problems?
Not easily, I don’t think. Depends on whether JEdit uses AWT or Swing (though I’m pretty sure it uses Swing).
AWT works out-of-the-box with GCJ on GNU/Linux (it’s not *totally* complete, but it works) and requires that you have GTK+ installed. On Mac OS X, besides needing GTK+ installed, getting AWT to work is a little tricky right now. This post:
http://gcc.gnu.org/ml/java/2004-05/msg00135.html
explains some of the details. (Note the screenshot linked to in the post.)
I’m told that GCJ/Classpath AWT and Swing development is moving along quite quickly though.
Apple’s Java implementation is quite nice. However, some apps can still benefit from native compiles via gcj. Also, each project is unique (as are each client/customer). So, if gcj can compile to native successfully and work correctly, it could be a huge benefit to some developers.
As I mentioned earlier, the combination of SWT and native via gcj could be really relevant for decreasing memory footprint and startup time, even if the overall app did not function faster after startup. I’m looking forward to testing this out with SWT this weekend.
I’ve experienced no such problems with JEdit under Panther. Try playing with the settings (especially text rendering) as JEdit supports some options that might jeopardize stability.
Which version of JEdit are you using?
I am not the only one either, I did a search on the jedit community forums and there are lots of people having these issues. I’ll look at text rendering and see if that helps any.