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; //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 [EMAIL PROTECTED]
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
