ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Levy-Lambert" <levylamb...@tiscali-dsl.de>
Subject Re: Request: Change <javac> debug default to "on"
Date Tue, 05 Nov 2002 21:10:57 GMT
Greetings,

In my previous experience with a large European investment bank, we had to
make our special release of ant 1.4 to get class files able to generate
stack traces while compiling with jdk 1.2. So I agree fully with Philip
Johnson, the reduction in community confusion and adhesion to principle of
least astonishment are very important.

Magesh Umasankar has it right to say that it might break a few
buildomations. However Joseph Dane 's viewpoint "Automatically retaining
questionable decisions because of an unwillingness to break compatibility
reduces the overall effectiveness of the tool." makes a lot of sense to me.
Softwares or organizations whose problems are not corrected become less and
less popular. I believe that the cost of changing xml files where debug=off
is really wished should be minimal, the benefit of having happy ant users
and less questions on google is higher than this cost.


Antoine Lévy-Lambert
Dehnhardtstr 19
60433 Frankfurt am Main
Germany
----- Original Message -----
From: "Philip Johnson" <johnson@hawaii.edu>
To: <ant-dev@jakarta.apache.org>
Sent: Tuesday, November 05, 2002 7:58 PM
Subject: Request: Change <javac> debug default to "on"


> Greetings,
>
> I am writing to request that the <javac> target attribute "debug" have its
> default value changed from "off" to "on" in the next release of Ant.  My
> request is based upon the following cost-benefit analysis:
>
> Benefits of changing the default debug attribute value to "on":
>
> 1. Reduction in community confusion.  A google groups search on "ant debug
line
> numbers" finds numerous instances where developers found that line numbers
were
> "mysteriously" missing from their stack traces after switching to Ant. By
> making <javac>'s default debug value "on", this confusion would disappear.
>
> 2. Adherence to the principle of least astonishment.  By default, Sun's
javac
> program inserts debugging information into the .class files (so that, for
> example, line number information can be provided in stack traces.)
Adherence to
> the principle of least astonishment suggests that <javac> provide the same
> default behavior as Sun's javac program.  This will make <javac> behave
more
> predictably and be easier to understand.
>
> 3. Improve debugging in the field.  The current default <javac> behavior
> produces .class and .jar files that do not contain debugging information.
This
> will inevitably give rise to many systems being distributed into the field
> without the presence of debugging information in the binaries. This will
in
> turn reduce the ability of developers to understand and solve problems
that
> occur in the field.
>
> 4. Improve development-time debugging.  The primary application of Ant is
to
> support the software development process.  The presence of a default value
which
> actually impedes development is counter-intuitive.
>
> Costs of changing the default debug attribute value to "on":
>
> 1. Implementation costs. Trivial. One line of code must be changed in the
> <javac> target class source code: the boolean declaration of debug must be
> changed from "false" to "true" in org.apache.tools.ant.taskdefs.Javac:
>       :
>     private String encoding;
>     private boolean debug = false;         file://Change to true
>     private boolean optimize = false;
>       :
>
> 2. Backward compatibility costs. Virtually none.  No previously working
> build.xml files will now fail to work after this change is implemented.
The
> only change apparent to the developer will be in the case that they do not
> explicitly specify the "debug" parameter to <javac>. In this case, the
size of
> their .class files will increase somewhat.  For an application we are
working
> on (approximately 200 classes and 15,000 LOC), the average increase in
.class
> size is 34%, but the resulting .jar file is increased by only 27%.  For
typical
> application development, I believe this size increase is not important,
and of
> course can always be addressed by manually setting debug to off.
>
> Cheers,
> Philip Johnson
>
> ____________________________________________________________________
> Philip Johnson                  http://csdl.ics.hawaii.edu/~johnson/
> Professor                                         johnson@hawaii.edu
> Collaborative Software Development Laboratory
> Department of Information and Computer Sciences
> University of Hawaii
> 1680 East West Road                                   (808) 956-3489
> Honolulu, HI 96822                               Fax: (808) 956-3548
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message