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