On Oct 26, 2005, at 6:49 AM, Colbert Philippe wrote:
> I want to show you that itís a big mistake that is costing you a
> great deal of money.
Colbert, I am a computer science professor. I do not make money off
of ECJ except in the sense of grants for graduate students that I
receive as a result of the software. It exists primarily because it
benefits my research efforts, and I will not make changes to it that
will hinder them. I believe you are underestimating the benefit that
ECJ has provided to the community.
> Sean, you should be careful before your criticize an award winning
> 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
> 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.
I will not debate this with you other than to suggest that you google
for combinations of ant/make/slower; and to mention that while it's
true that ant only fires up one javac process, we don't use javac at
all (and besides, we only have one compile at present anyway).
Ant's speed is not the issue anyway. I am comfortable with make, our
build needs are extremely simple (a single compile), and Ant does not
benefit me as a developer. If the community would like to provide an
ant script, that's reasonable, but as I don't use it, it is not
reasonable to ask me to update it.
As to awards: there is no accounting for taste, I guess. ;-)
> 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.
THIS is an important discussion. ECJ's testing is in-house and quite
ad-hoc. The software long predated jUnit and the unit testing
religion, but I think ECJ would benefit considerably from a suite of
jUnit tests. For example, we recently performed a long-overdue major
overhaul to the ES package, and in the process appear to have broken
the 1/5 rule feature. A unit test would have caught that. That
being said, my resources are limited and I must rely on others to
provide unit tests (something that I think would be very helpful).
> 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 cannot speak as to whether or not 1.5's changes to the bytecode
result in faster VM performance on the J2SE 5.0 VM. But that's just
a compile decision the user can make trivially. What I want to avoid
is using Java 1.5-only *language* features for the time being. I am
not aware of any API changes which would enhance ECJ's performance,
and the major syntax changes (new for-loop;generics;etc.) contribute
nothing to performance, and in fact generally slow it down when used
> ECJ could probably be significantly simplified if the old and
> optimization would be taken out.
ECJ also tries to be as backward-compatible as possible. The changes
I've been making have tried to maintain compatibility as much as
possible to reduce the pain people endure when upgrading to new
versions of the software. If you have optimization-reduction
suggestions within these constraints, I welcome them.
> I donít really ask that you to make all the changes to ECJ. I am
> to do most of it. All I ask is that we have a common ground that is
> standard and universally accepted.
The changes you're proposing are easy to implement. What I'm trying
to get across is that most of them will make ECJ a harder environment
for _me_ to develop in, even if they benefit certain others. Given
that I and my students are the primary developers of ECJ, that
wouldn't be a good thing for either us or the community.