----- Original Message ----- From: "Philip Johnson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 10:58 AM 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: ahh, we are into controversy land indeed. > 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. It does occur, but mere noise compared to the 'ant always rebuilds' issue that crops in in many bugreps. > 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. I believe that historically ant did just that, then (in 1.3?) it switched to debug=line numbers only, then the current solution came in (1.4?) : you can control what goes in. > 3. Improve debugging in the field. The current default <javac> behavior > produces .class and .jar files that do not contain debugging information. only for products that are built with default options > 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. If you are redisting end user products for money then you may want to obfuscate as well as include no debug info. Server side you take little hit by including debug info, but even if you forget it the cost of turning the switch on and redeploying is minimal. Even for webstart client stuff its easy to change your mind. Its the download-by-ftp install path that is trouble. Incidentally, some introspection-based stuff, such as WSDL generation in Axis and JAX-RPC needs debug info to generate meaningful parameter names in WSDL, and I dont think the JAX-RPC exception marshalling will work without it. Which is another argument in favour of debug=true > 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. I can see you have just had a bad experience here :( > > 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; Plus the cost of writing a test to verify that debug info is included. New code changes have the hurdle of needing accompanying tests, to encourage the growth of the test base in ant. > 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. Mobile java is a special case; debug info can be enough to break the install. Plus there is the general hit to download time. That doesnt mean the default is idea where it is, but that people doing some apps really do need to know what is going on. -------------- I understand your perspective. I appreciate your analysis, And I am not convinced that the current default setting is correct. But I dont like changing it for the following reasons 0. Everyone who 'knew' what the default value is has just suffered a semantic attack, as we alter the validity of their memory 1. It introduces a difference in behaviour between ant versions, which means builds, build differently. We hate having to do that, as hate mail always piles in. 2. I prefer users to know what they are doing. In an ideal world, javac would make the debug setting mandatory and you would have to explicitly decide what you wanted. That way: no confusion, no need to know what the secret default value was depending on the ant version you ran. But we cannot do that without breaking things. -steve -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
