-1 I don't think Ant should sacrifice backwards compatibility - in such cases, Ant Dev's approach has mostly been to retain existing behavior while allowing new behavior to be configured with additional attributes.
Wrongly assuming decisions like these have no negative costs, may impact existing buildomations in a variety of ways. Cheers, Magesh ************************************************** * The surest sign that intelligent life exists * * elsewhere in the universe is the fact that it * * has never tried to contact us. * ************************************************** ----- Original Message ----- From: "Philip Johnson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 1: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; //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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
