ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Request: Change <javac> debug default to "on"
Date Tue, 05 Nov 2002 20:31:23 GMT

----- Original Message -----
From: "Philip Johnson" <>
To: <>
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
> numbers" finds numerous instances where developers found that line numbers
> "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
> 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
> 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
> turn reduce the ability of developers to understand and solve problems
> 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

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
> support the software development process.  The presence of a default value
> 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
>       :
>     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.
> 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
> on (approximately 200 classes and 15,000 LOC), the average increase in
> size is 34%, but the resulting .jar file is increased by only 27%.  For
> 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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message