ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <>
Subject RE: jikes and Ant vs. javac 1.3
Date Fri, 16 Feb 2001 12:53:52 GMT
> -----Original Message-----
> From: Peter Donald []
> At 02:41  15/2/01 -0500, Jay Glanville wrote:
> >Interestingly, I've found (my non-official and 
> non-quantitative analysis
> >opinion) that javac from 1.3 is comparable, if not better 
> (sacrilege!!) then
> >jikes.  Jikes CERTAINLY outperforms javac from 1.1.x and 1.2.x, but I
> >believe that the javac from 1.3 has been totally re-written 
> and performs
> >much better.
> I am curious what makes you say this. I just rerun tests on 
> compiling for
> 80, 300, 500 and 1000 files. Jikes comes out in front each 
> time. Then I
> removed 10 files from each and recompiled. Still jikes came 
> out faster. I
> ran it on FAT32 system (win98se) and ext2 (linux) system and 
> found the same
> results so it is not the filesystem. Can you tell me your 
> environment and
> if there is anything exceptional about it?

For me, the difference is basically a 5:30 minute compile with ant using
javac1.3 and a 6:00 minute compile using jikes (these times are averages).
However, because my source code is on a clear case mount, and times can

After re-reading my above paragraph, I think my last sentence should read:
"Jikes certainly outperforms javac from 1.1 and 1.2, but I believe that the
javac from 1.3 has been totally re-written and performs much better then
it's predecessors and comparable with jikes."

In my opinion, the difference of +-15 seconds difference between the two on
a 5 minute build is ignorable.  

> >I have actually found that the error checking from javac 1.3 
> to be more
> >strict then jikes (jikes will SOMETIMES miss things like 
> case statements
> >where the case label is based on a variable, but javac 1.3 
> will catch this
> >error).
> turn on pedantic mode in jikes and you will find it is much 
> much muh more
> conformant than javac ;)

I believe that conformancy is now getting into the subjective realm.
Neither compiler is 100% compliant, but when used together (duplicating
compiler coverage) you can really check to see if your code is compliant or

The two errors that frequently cause our loadbuild to break (because our
designers don't think of them as errors) are extra semi-solons (jikes
catches this, but javac1.3 doesn't) and using variables as part of your case
statement (jikes doesn't catch this, while javac1.3 does).

Here is an example of the second problem.  The code is a copy from bug
#4266342 at sun's developer connection:
   import java.awt.event.MouseEvent; 
   public class CaseTest { 
       public void processMouseEvent (MouseEvent event) { 
           switch (event.getID ()) { 
           case MouseEvent.MOUSE_PRESSED: // OK 
           case event.MOUSE_RELEASED: // Not constant by JLS 15.27 
javac1.3 stops at the second case statement, claiming that it's not a
constant (I believe that the philosophy is what should the interpreter do if
the "event" variable is null?)  jikes does have a jacks test for this, but
no solution as of yet.

Of the two errors mentioned (extra semi-colons and non-constant case
labels), I consider the second to be more of an error then the first.  (Lets
face it, an extra semi-colon is simply an empty expression.)  Therefore, for
us (and I stress the "us"), javac1.3 is more compliant.  Again, compliancy
is subjective as neither compiler is 100% compliant with the JLS.

> >Another advantage of javac 1.3 over jikes is that javac 1.3 
> fully supports
> >the JPDA structure, which many debuggers use.  I.e.: if you 
> use jikes to
> >compile, and then use JSwat to debug, JSwat might complain 
> about not being
> >able to fully find all the debugging information.  Please 
> confirm this
> >before you take what I say as gospel.
> yup ;( jikes is busted for those debuggers.
> Cheers,
> Pete

The focus of my original posting was basically that it really doesn't matter
that much between jikes and javac1.3.  Just a matter of preference (if you
ignore the debugger thing).


We the willing, led by the unknowing, are doing the impossible for the
ungrateful. We have done so much for so long, with so little, we are now
qualified to do anything with nothing. - Unknown Software Developer

View raw message