Print

Print


Point well taken Mr. Coles.

However, Sean Luke rejects using ANT because, according to him, too slow for
him.  That is the opposite of the experience of millions of coders who can't
waste time and moved to ANT when compiling Java and using Java related
tools.  I have no idea what Sean Luke is talking about.   ANT is ultra-fast
because the JVM is loaded once for ANT and the same JVM is used for the
compiler and Jar!

Using your own words; If ECJ is a simple project, why is it so difficult to
get update it?  There are already a number of break-offs of ECJ done
privately to modernize it.  I am trying to do it with the full approval and
collaboration of Sean Luke (as much as possible).

Your idea of using ECJ for generating unit testing is great.  I beleive it
was done and was documented in an academic paper.

CP



----- Original Message -----
From: "George Coles" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, October 26, 2005 9:38 AM
Subject: Re: One objection leads to another objection and anotherÖetc!


> Colbert,
>           In my experience, ECJ's relative simplicity, compared to the
> large business apps that you mentioned, allows for quite a trivial ant
> script to compile and archive the files into a jar. I do not think that
> the ANT vs Make debate is worth pursuing in this forum.
>
> Unit tests, on the other hand, might be a great project. As an exercise,
> evolving a suite of unit tests, using ECJ itself, to ensure the
> correctness of ECJ under changes might be fun.
>
> George Coles
>
> Colbert Philippe wrote:
>
>>Hello Sean!   This is Colbert Philippe.
>>
>>Thanks for a detailed reply to the question of updating ECJ.  I appreciate
>>your precise style.   Thatís what is required in software engineering.
>>Your style encourages me to get more involved in ECJ.   My goals are
>>simple: I want to use ECJ and take it to the next step.  I want to make
>>ECJ usable on personal computers or on grid servers where availability,
>>power is plentiful for a relatively small cost.  I feel that ECJ is almost
>>there if it can be modernized.   I donít have legacy obligations like you
>>so I might have to branch off ECJ.  However, I was hoping to convince you
>>to have a common base that is standard and universally accepted.
>>
>>Sean, Java is used all over the world in projects that are much bigger
>>than ECJ.  ECJ has only 363 files and does not qualify as a big project.
>>I have seen projects with over 10000 files with bigger sources too (mostly
>>in the business not so much scientific).  There is a huge community of
>>programmers out there in the commercial community and the open source
>>community.  The total expertise, the collective intellect and the review
>>capabilities of communities is one of the most power human intellectual
>>engine.
>>
>>Javaís success is partly due to its compliance with standards or common
>>ways of doing things.  VisualBasic, Fortran, C/C++ has very few effective
>>standards which incurred great costs to everybody involved.  You donít
>>seem convinced of this wisdom.  I am.  I want to show you that itís a big
>>mistake that is costing you a great deal of money.
>>
>>I understand your biases given the history of ECJ.  Thatís normal.   Every
>>project has that.  However, I want to show you the other side of the
>>coin.   Java and popular java tools have been reviewed by a huge number of
>>people.  The error tracking in developing java is extraordinary for a
>>language that is platform independent.   There are solid reasons why
>>changes are done to upgrade Java.   Itís not syntax candy.
>>
>>Sean, you should be careful before your criticize an award winning utility
>>like ANT.  They donít give awards to lame utilities.    You are the only
>>(I mean the only) person I hear saying that ANT is slower than MAKE.  It
>>is impossible.   You need to demonstrate your claim with precise numbers.
>>ANT is ultra-fast, much faster than MAKE.   The reason is simple:  MAKE is
>>not tuned to Java.   MAKE is coded in C/C++.   MAKE invokes a new java
>>instance sequentially on every wildcard expression.  On the other hand,
>>ANT generally (can be turned-off) invokes java only once and feeds it the
>>wildcard expressions.  That saves a lot of time. I should know because I
>>played with ANT code to grab sections of it for a previous project.   I
>>talked to the guys who coded ANT several times.   They are very smart and
>>capable.  MAKE will reload the JVM on every expression while MAKE will
>>not.   The speed of ANT has been demonstrated in front of me hundreds of
>>times.  You will have to prove your claim that MAKE is faster than make
>>with precise numbers.   I suspect that ANT might run slower on your
>>projects because you are doing something wrong or unusual.  I am
>>speculating that it might have to do with your directory structure, which
>>is non-standard (really donít know).
>>
>>When you donít follow standards or common ways of doing things, you end up
>>following unproven, inefficient and unbeaten paths.  One objection leads
>>forcibly to another objection and forcibly to another objection and
>>anotherÖetc.
>>
>>Let me give you a clear example of this:
>>
>>∑ By not using ANT, you are missing out on a lot of good, time-
>>saving things like testing using testing frameworks like Junit (and
>>related utilities), source file dependency viewers, archiving, and a huge
>>amount of utilities that save time and make life easier.   How do you test
>>ECJ anyways?  A minimal amount of testing is necessary.
>>∑ By not updating to the latest Java compiler (currently Java 1.5),
>>you are not benefiting from a number of performance enhancements put into
>>the JVM.  I am pretty sure that Java 1.5 has for the fist time object
>>recycling (I read it in Sun article).   This can save you from doing all
>>sorts of optimizations.  Furthermore, there are frameworks for doing more
>>involved object recycling using AspectJ.   Most of these tools rely on the
>>generic feature of Java.   Generics are not syntax sugar.  You are not
>>benefiting from any of these facilities.
>>
>>ECJ could probably be significantly simplified if the old and unnecessary
>>optimization would be taken out.  Also, I feel that ECJ should use more
>>open-source utilities to again reduce the amount of sources.   As for the
>>coding style, itís entirely your decision.  I personally think you should
>>vote on it.  If you keep the same style, me and others are going to have
>>to run a styling program every time the code gets checked-out.  Itís not a
>>problem, just an extra step.
>>
>>I donít really ask that you to make all the changes to ECJ.  I am willing
>>to do most of it.  All I ask is that we have a common ground that is
>>standard and universally accepted.
>>
>>I hope we can talk more about these issues.
>>Colbert Philippe
>>
>>
>>