OK, there was a lot of discusion about jikes on this thread, and rather
than post a bunch of little comments on each of the off shoot threads I'll
bundle it all up here....
Riyad didn't miss anything, jikes can do a hell of a lot of files in the
blink of an eye. The bigest reason is that it is written in _C_. FYI: javac
may look like a native binary, but it is just a wrapper around a jni call
to "java sun.tools.javac.Main".
A couple people mentioned that javac will recompile any classes referenced
by what you compile and recompile them if they're newer... true, but DON'T
RELY ON THAT to save you: it misses the opposite link. Say for example you
have a static final boolean, and you change it... any class which uses it
must now be recompiled. Jikes figures out dependencies for each file you
compile. You can take advantage of this feature with the incremental
compile option. For example: say you have a project with a dozen or so
.javas execute "jikes ++ *.java" and it will churn through and compile
everything, then put out a prompt asking you to hit enter, go edit your
code, come back to the shell jikes is running in and hit enter... it will
recompile only the classes that need it, including the ones like I
mentioned above.
Some others lamented about trying to keep make dependencies up to date.
Jikes can do that too... try "jikes +M *.java" to get *.u or "jikes
+M=depends.file *.java" to get a file with the full dependencies in
makefile format. Plus both of these dependencies issues have +U and +F
options to control just how anal jikes gets about dependencies. (in full
anal retentive mode it even checks into zip and jar files that you don't
let it have the source for!)
Then there was the question about the relative performance of class files
generated by jikes vs other compilers. I like to spend time in byte code.
(yes, I know :) I'm a GEEK... What's your point?? ;) So I've taken apart a
few .class files from a couple different compilers... jikes is currently
very simplistic in the optimizations it does... if any. Sun's javac is
focused far more on the performance of the end code over the performance of
the compiler, it seems at any cost.... Some of my earlier comparisons
showed jikes generated code orders of magnitude slower than javac generated
code; more recently the difference is less, but still noticable for the
stuff I work on (takes an extra three hours to run one of our build
verification test buckets that only needs about six hours with output from
javac).
Jikes stable comes from www.alphaWorks.ibm.com/tech/jikes/ (currently v0.47)
Jikes devel comes from www.research.ibm.com/jikes (currently v0.55)
And no, I'm not part of the jikes development team (at times I wish I could
get a transfer to research though...) Just to prove I'm not here's a
_problem_ with using the stuff I've just been talking about:
Since jikes is native code it doesn't live in a limited heap with a GC
system under it... for large compilations this can eat up a LOT of
memory... I have twice now sent my 256M machine into thrash mode by asking
incremental compile to work with too many classes (in the neighborhood of
8K .javas).
Sorry for rambling so long all. -=Chris
cabbey at home dot net <*> http://members.home.net/cabbey
I want a binary interface to the brain!
Today's opto-mechanical digital interfaces are just too slow!
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
