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
>
>
>