You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Philip Johnson <jo...@hawaii.edu> on 2002/11/05 19:58:55 UTC
Request: Change 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 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Joseph Dane" <jd...@lava.net>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Tuesday, November 05, 2002 12:15 PM
Subject: Re: Request: Change <javac> debug default to "on"
> But I should probably ask: why was the decision originally made to
> make the default "no-debug"?
you have to go back through the annals of CVS to find out.
... DefaultCompilerAdapter patch 1.4 on 2001-03-28 fixed
Bug #1011
If debug is set to false pass -g:none to javac if JDK 1.2 or JDK 1.3 to get
really no debug information at all.
-----
debug=false has been the way it was since the CVS repository existed, so
that's a 'dont know'. I'd assume because the tomcat team were writing a tool
to build tomcat, not a generic dev tool.
Looking at command javac.exe, the default there is not -g , give out
everything, but -g: source and lines.
Prior to bug#1011 being fixed (which meant ant never ever generated files
without some debug), ant defaulted to always generating some debug info,
probably lines and source. It did this by not saying anything to javac and
taking its defaults.
So...up to ant1.3 the situation was
debug=false was the default, but you really got -g:lines,source
in ant1.4 you got
debug=false was the default, and you really got -g:none
in ant1.5 we got
debug=false was the default, but you could select which options to debug.
When you set debug=true the default was -g:source,lines,vars
So if people are trying to fix things to be compatible with javac and
backwards compatible, they come up with a system that
-defaults to -g: source,lines
-when debug=false really generates nothing
-when debug=true really generates everything
Plus the tests to verify it. You can use commons-discovery to look at the
debug info.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Stephane Bailliez <sb...@apache.org>.
----- Original Message -----
From: "Magesh Umasankar" <um...@apache.org>
> A change to the existing behavior of <javac> practically
> means a rewrite of *every* ant build file out there.
> By making this change, we are forcing every build file
> to be rewritten to retain existing, and in most cases,
> accepted behavior, when an ant upgrade is made.
In essence I agree. In essence I do not.
It should not be underestimated how we could inadvertantly help people
shooting themselves in the foot with debug=false and includeantruntime=true.
I believe indeed that once the whole planet will be used to this invisible
behavior we will have a hard time taking it out. Another 'referer' for
life....
Maybe this should be added as a warning note in <javac> doc but then again
people using it for years will not bother looking at the docs. Might help
newcomers though if it is never fixed, we'd better push for 'correct'
ways...thoughts ?
I think that even though this bug does not manifest itself in a crash, it
might not be a reason not to consider it as indeed there is history.. I
think this a purely a psychological problem from the 'if it ain't broken
don't fix it' paradigm and that we like better to fix things when it
crashes, even though I have seen people coding against bugs...meaning that
any fix in the API would cause a breakage in the user code...we can go a
long way like this. That means we must stop fix bugs ;o)
The includeantruntime is WAY more problematic to me. Users are addicted to
it. It will create definite trauma. It will be just like removing social
security in France. :)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Costin Manolache <cm...@yahoo.com>.
IMO - if you want debugging, you should use debug="true",
if you don't want - false.
Most build.xml files I use have one of those settings.
My assumption is that if you don't specify either - you
don't care :-)
I would vote +1 to have the default set to 'debug=true' -
for the simple reason that people who don't care or
don't know will get the line numbers in stack traces.
And I think they'll need them the most :-)
Costin
Magesh Umasankar wrote:
> ----- Original Message -----
> From: "Ken Wood" <kw...@i2.com>
>
> You are right - maybe the original post should have
> first addressed ant-user to see if such a change
> would adversely affect users. If not, then, I will
> withdraw my objection in ant-dev though I would
> scream in ant-user, I being one ;-) I am not
> suggesting somebody start a vote in the user forum -
> that is, unless, s/he feels very strongly about this...
>
>> Personally, I don't put much merit to any argument that
>> says we can't make a change because build files would
>> have to change.
>>
>> Every time I switch to a new version of Ant, I'm switching
>> to take advantage of some new capability.
>
> What if - you write your build.xml for your own reusable
> sub-module. There is this consumer module that invokes your
> build file.
>
> If the Consumer App uses 1.6, should you be forced to
> change your build file which was written for 1.5 and
> make it different with ConsumerAppB which uses 1.5?
>
> There are ways to address this issue, but what
> I am trying to point out is that one must not be
> forced to change something unless there is a very
> pressing need - in this case, I just don't see it.
>
>> So, I gotta
>> change my build files anyhow. I just don't buy the 'build
>> files' argument...
>
> Cheers,
> Magesh
>
> PS: Being an Ant user (not just a dev guy), I wouldn't
> be thrilled to change my numerous <javac> invocations
> just so that I can use a new feature being provided
> to me by an upgrade.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Magesh Umasankar <um...@apache.org>.
----- Original Message -----
From: "Ken Wood" <kw...@i2.com>
You are right - maybe the original post should have
first addressed ant-user to see if such a change
would adversely affect users. If not, then, I will
withdraw my objection in ant-dev though I would
scream in ant-user, I being one ;-) I am not
suggesting somebody start a vote in the user forum -
that is, unless, s/he feels very strongly about this...
> Personally, I don't put much merit to any argument that
> says we can't make a change because build files would
> have to change.
>
> Every time I switch to a new version of Ant, I'm switching
> to take advantage of some new capability.
What if - you write your build.xml for your own reusable
sub-module. There is this consumer module that invokes your
build file.
If the Consumer App uses 1.6, should you be forced to
change your build file which was written for 1.5 and
make it different with ConsumerAppB which uses 1.5?
There are ways to address this issue, but what
I am trying to point out is that one must not be
forced to change something unless there is a very
pressing need - in this case, I just don't see it.
> So, I gotta
> change my build files anyhow. I just don't buy the 'build
> files' argument...
Cheers,
Magesh
PS: Being an Ant user (not just a dev guy), I wouldn't
be thrilled to change my numerous <javac> invocations
just so that I can use a new feature being provided
to me by an upgrade.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Ken Wood <kw...@i2.com>.
Rather than debate it, why not ask the folks
on ant-users list to vote for or against the proposed
change in default behavior?
Us developers are notorious for thinking we know
what the user wants... and being wrong. Why spend
days debating the merits of changing the default when
we can ask the users how they feel?
Personally, I don't put much merit to any argument that
says we can't make a change because build files would
have to change.
Every time I switch to a new version of Ant, I'm switching
to take advantage of some new capability. So, I gotta
change my build files anyhow. I just don't buy the 'build
files' argument...
Joseph Dane wrote:
> "Magesh Umasankar" <um...@apache.org> writes:
>
> > A change to the existing behavior of <javac> practically
> > means a rewrite of *every* ant build file out there.
>
> Well, maybe if "every" is defined to mean "every buildfile except
> mine", since I do not personally rely on the default behavior, and I
> don't see how this change would force me to change my buildfiles.
>
> > By making this change, we are forcing every build file
> > to be rewritten to retain existing, and in most cases,
> > accepted behavior, when an ant upgrade is made.
>
> Again, "every"?
>
> It has already been demonstrated the javac task *has* changed in
> previous releases of Ant. Where was the widespread confusion and
> panic?
>
> > How is its effectiveness reduced? You can still
> > configure it the way you want it to behave - just
> > because you don't like the default doesn't make it
> > any less effective.
>
> Not to me personally, since I don't rely on the defaults. But the
> intent behind the proposal, at least as I understood it, was to reduce
> confusion in *new* projects and users. I can absoluetly see the
> benefit to this population, and I can't see how they are being served
> by a decision to retain the status quo.
>
> It all boils down to cost/benefit. Clearly, I understated the cost
> with my initial "no brainer" response, but I still think that the
> benefit to the Ant user population (present and future) outweighs the
> cost.
>
> Anyhow, that's my 2c.
>
> --
>
> joe
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Joseph Dane <jd...@lava.net>.
"Magesh Umasankar" <um...@apache.org> writes:
> A change to the existing behavior of <javac> practically
> means a rewrite of *every* ant build file out there.
Well, maybe if "every" is defined to mean "every buildfile except
mine", since I do not personally rely on the default behavior, and I
don't see how this change would force me to change my buildfiles.
> By making this change, we are forcing every build file
> to be rewritten to retain existing, and in most cases,
> accepted behavior, when an ant upgrade is made.
Again, "every"?
It has already been demonstrated the javac task *has* changed in
previous releases of Ant. Where was the widespread confusion and
panic?
> How is its effectiveness reduced? You can still
> configure it the way you want it to behave - just
> because you don't like the default doesn't make it
> any less effective.
Not to me personally, since I don't rely on the defaults. But the
intent behind the proposal, at least as I understood it, was to reduce
confusion in *new* projects and users. I can absoluetly see the
benefit to this population, and I can't see how they are being served
by a decision to retain the status quo.
It all boils down to cost/benefit. Clearly, I understated the cost
with my initial "no brainer" response, but I still think that the
benefit to the Ant user population (present and future) outweighs the
cost.
Anyhow, that's my 2c.
--
joe
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Magesh Umasankar <um...@apache.org>.
----- Original Message -----
From: "Joseph Dane" <jd...@lava.net>
> > I don't think Ant should sacrifice backwards
> > compatibility - in such cases, Ant Dev's approach
>
> Is compatibility really sacrificed here?
Yes.
> Sure, the change should be documented like any other change,
> but can people really expect a new version of a tool like
> ant to behave in exactly the same way as the previous version?
A change to the existing behavior of <javac> practically
means a rewrite of *every* ant build file out there.
By making this change, we are forcing every build file
to be rewritten to retain existing, and in most cases,
accepted behavior, when an ant upgrade is made.
>
> > Wrongly assuming decisions like these have no negative
> > costs, may impact existing buildomations in a variety of
> > ways.
>
> Automatically retaining questionable decisions because of an
> unwillingness to break compatibility reduces the overall effectiveness
> of the tool.
How is its effectiveness reduced? You can still
configure it the way you want it to behave - just
because you don't like the default doesn't make it
any less effective.
> But I should probably ask: why was the decision originally made to
> make the default "no-debug"?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1011
...and related to this...
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5167
> joe
Cheers,
Magesh
**************************************************
* The surest sign that intelligent life exists *
* elsewhere in the universe is the fact that it *
* has never tried to contact us. *
**************************************************
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Joseph Dane <jd...@lava.net>.
"Magesh Umasankar" <um...@apache.org> writes:
> I don't think Ant should sacrifice backwards
> compatibility - in such cases, Ant Dev's approach
Is compatibility really sacrificed here? Sure, the change should be
documented like any other change, but can people really expect a new
version of a tool like ant to behave in exactly the same way as the
previous version?
> Wrongly assuming decisions like these have no negative
> costs, may impact existing buildomations in a variety of
> ways.
Automatically retaining questionable decisions because of an
unwillingness to break compatibility reduces the overall effectiveness
of the tool.
But I should probably ask: why was the decision originally made to
make the default "no-debug"?
--
joe
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Philip Johnson" <jo...@hawaii.edu>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Tuesday, November 05, 2002 1:36 PM
Subject: Re: Request: Change <javac> debug default to "on"
>
> But Steve Loughran reveals that Ant has been sacrificing backwards
> compatibility and changing the existing behavior of <javac> in the last
three
> releases:
>
> > So...up to ant1.3 the situation was
> > debug=false was the default, but you really got -g:lines,source
> >
> > in ant1.4 you got
> > debug=false was the default, and you really got -g:none
> >
> > in ant1.5 we got
> > debug=false was the default, but you could select which options to
debug.
> > When you set debug=true the default was -g:source,lines,vars
>
> Thus, we have an existence proof that the debug default setting can be
changed
> without creating community trauma.
I provided proof of change, not proof of absence-of-trauma.
indeed, the changes in ant1.5 were effectively a fix for the trauma
introduced by ant1.4, as in that version you only had two choices: all debug
or no debug, compared the previous choices of : enough debug to handle a
support call, or full debug. This was a major (and accidental) breakage. We
werent changing the default, so much as changing the semantics of
debug=false
Also note that the a usage of ant has increased over time, it is becoming
harder and harder to change things. We have so much inertia that any change
we make breaks something, somewhere.
> > So if people are trying to fix things to be compatible with javac and
> > backwards compatible, they come up with a system that
> > -defaults to -g: source,lines
> > -when debug=false really generates nothing
> > -when debug=true really generates everything
>
> Sounds good to me.
well, see what the consensus is, feel free to write the fix, the docs and
the tests. Yes, tests make adding the fix that much harder, look on it as
creating a barrier to excessive change.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Philip Johnson <jo...@hawaii.edu>.
Magesh Umasankar summarizes the "don't break compatibility" argument as follows:
> 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.
and:
> A change to the existing behavior of <javac> practically
> means a rewrite of *every* ant build file out there.
But Steve Loughran reveals that Ant has been sacrificing backwards
compatibility and changing the existing behavior of <javac> in the last three
releases:
> So...up to ant1.3 the situation was
> debug=false was the default, but you really got -g:lines,source
>
> in ant1.4 you got
> debug=false was the default, and you really got -g:none
>
> in ant1.5 we got
> debug=false was the default, but you could select which options to debug.
> When you set debug=true the default was -g:source,lines,vars
Thus, we have an existence proof that the debug default setting can be changed
without creating community trauma.
> So if people are trying to fix things to be compatible with javac and
> backwards compatible, they come up with a system that
> -defaults to -g: source,lines
> -when debug=false really generates nothing
> -when debug=true really generates everything
Sounds good to me.
Philip
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Magesh Umasankar <um...@apache.org>.
-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" <jo...@hawaii.edu>
To: <an...@jakarta.apache.org>
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 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Joseph Dane <jd...@lava.net>.
This sounds like a no-brainer. A non-binding +1 from me.
--
joe
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Philip Johnson" <jo...@hawaii.edu>
To: <an...@jakarta.apache.org>
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Gus Heck <gu...@cognition.olin.edu>.
> 2. Backward compatibility costs. Virtually none. No previously working
> build.xml files will now fail to work after this change is implemented.
This depends on your definition of "work". If work means run to
completion without errors, you are correct. If work means produce the
same output as before, no. This may translate into a silently appearing
30% increase in download time and network bandwith... If you pay per GB
for bandwith this could matter a lot. What happens when the 30% increase
in size pushes it over the limit for the media being used to package a
product and the user doesn't know why? They probably figure they are
accidentally including something in a fileset somewhere...
In some ways this sort of silent, non-error producing behavior change is
worse because it is harder to diagnose and fix. Your points are very
good and this change might still be a good idea, but I don't think it is
a nobrainer and ant should be VERY loud about publicizing this change if
it is implemented.
-Gus
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Request: Change debug default to "on"
Posted by Antoine Levy-Lambert <le...@tiscali-dsl.de>.
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" <jo...@hawaii.edu>
To: <an...@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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>