Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13382 > unrolled thread

How to turn off those warning messages during ant build?

Back to article view | Back to comp.lang.java.programmer

Contents

  How to turn off those warning messages during ant build? zyng <xsli2@yahoo.com> - 2012-04-04 06:29 -0700
    Re: How to turn off those warning messages during ant build? Lew <lewbloch@gmail.com> - 2012-04-04 10:54 -0700
    Re: How to turn off those warning messages during ant build? Roedy Green <see_website@mindprod.com.invalid> - 2012-04-04 13:05 -0700
      Re: How to turn off those warning messages during ant build? Lew <lewbloch@gmail.com> - 2012-04-04 18:24 -0700
        Re: How to turn off those warning messages during ant build? Patricia Shanahan <pats@acm.org> - 2012-04-04 19:15 -0700
          Re: How to turn off those warning messages during ant build? Lew <noone@lewscanon.com> - 2012-04-04 19:39 -0700
            Re: How to turn off those warning messages during ant build? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-04-05 09:46 -0700
              Re: How to turn off those warning messages during ant build? Lew <lewbloch@gmail.com> - 2012-04-05 11:42 -0700
                Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-05 19:46 -0400
                  Re: How to turn off those warning messages during ant build? Gene Wirchenko <genew@ocis.net> - 2012-04-05 19:35 -0700
                    Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-12 20:27 -0400
                      Re: How to turn off those warning messages during ant build? Gene Wirchenko <genew@ocis.net> - 2012-04-12 19:29 -0700
                        Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 21:07 -0400
                          Re: How to turn off those warning messages during ant build? Lew <lewbloch@gmail.com> - 2012-04-14 12:53 -0700
                            Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-14 16:16 -0400
                              Re: How to turn off those warning messages during ant build? Lew <lewbloch@gmail.com> - 2012-04-14 13:37 -0700
                                Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-14 17:29 -0400
                                  Re: How to turn off those warning messages during ant build? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-15 01:25 -0500
                                    Re: How to turn off those warning messages during ant build? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-15 10:30 -0300
                                      Re: How to turn off those warning messages during ant build? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-15 11:16 -0500
                                    Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:48 -0400
                          Re: How to turn off those warning messages during ant build? Gene Wirchenko <genew@ocis.net> - 2012-04-15 19:54 -0700
                            Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:47 -0400
                              Re: How to turn off those warning messages during ant build? Gene Wirchenko <genew@ocis.net> - 2012-05-07 09:31 -0700
                          Re: How to turn off those warning messages during ant build? Gene Wirchenko <genew@ocis.net> - 2012-04-15 19:58 -0700
                            Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:50 -0400
                              Re: How to turn off those warning messages during ant build? Gene Wirchenko <genew@ocis.net> - 2012-05-07 09:33 -0700
                  Re: How to turn off those warning messages during ant build? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-05 22:41 -0400
                    Re: How to turn off those warning messages during ant build? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-06 19:53 -0300
                      Re: How to turn off those warning messages during ant build? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-06 21:35 -0400
                      Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-12 20:33 -0400
                        Re: How to turn off those warning messages during ant build? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-13 21:16 -0300
                          Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 21:03 -0400
                            Re: How to turn off those warning messages during ant build? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-13 22:51 -0300
                              Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:51 -0400
                    Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-12 20:29 -0400
                      Re: How to turn off those warning messages during ant build? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-04-12 21:28 -0400
                        Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 21:04 -0400
              Re: How to turn off those warning messages during ant build? Patricia Shanahan <pats@acm.org> - 2012-04-05 14:04 -0700

Page 1 of 2  [1] 2  Next page →

#13382 — How to turn off those warning messages during ant build?

Hi:

When I run ant, a lot of warnings are printed out on the screen. It is very daunting. It makes new people to feel, as first response, this is broken. But actually, the build is successful. I pasted a few warning messages below. In our real code, there are hundreds of them.

    [javac] /abc/efg/MyTools.java:125: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List
    [javac]             recursiveDirectoriesToBuild.add(workingDir);
    [javac]                             ^
    [javac] /abc/efg/MyTools.java:212: warning: [unchecked] unchecked call to Vector(java.util.Collection<? extends E>) as a member of the raw type java.util.Vector
    [javac]             return new Vector(v2);
....

I know one solution, the basic solution, is to going to the code and use Java Annotation feature to add "Ignore Warning etc" at those places. But there are so many places and the code were written by different people. We don't want to modify the code! I am wondering if ant has a feature to turn off the warning messages. 

This is my ant script to build:
	<target name="compile" depends="prepare">
		<javac srcdir="${src.dir}" destdir="${build.dir}" compiler="modern" fork="yes" debug="on">
			<classpath refid="project.classpath"/>
			<compilerarg value="-Xlint"/>
		</javac>
	</target>

To be honest, I do not know the feature "-Xlint" etc.

Thank you very much.

[toc] | [next] | [standalone]

#13383

zyng wrote:
> When I run ant, a lot of warnings are printed out on the screen. It is very daunting. It makes 

The warnings you cite are due to errors in your coding.

> new people to feel, as first response, this is broken. But actually, the build is successful. 
> I pasted a few warning messages below. In our real code, there are hundreds of them.
> 
>     [javac] /abc/efg/MyTools.java:125: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List
>     [javac]             recursiveDirectoriesToBuild.add(workingDir);

Don't use raw types!

That's an invitation to runtime bugs. Generics are there to pull these bugs back to compilation time, thus making them four to sixteen times cheaper to fix than if they were runtime bugs.

Do not use raw types.

>     [javac]                             ^
>     [javac] /abc/efg/MyTools.java:212: warning: [unchecked] unchecked call to Vector(java.util.Collection<? extends E>) as a member of the raw type java.util.Vector
>     [javac]             return new Vector(v2);

Why are you using 'java.util.Vector' instead of, say, 'java.util.ArrayList'?

> ....
> 
> I know one solution, the basic solution, is to going to the code and use Java Annotation 
> feature to add "Ignore Warning etc" at those places. 

That's not a solution!

That hides the problem without fixing it. There are rules to using '@SuppressWarnings("unchecked")'. You don't just use the annotation to hide problems.

> But there are so many places and the code  were written by different people. 

This is called "technical debt", and it is an issue.

> We don't want to modify the code! I am wondering if ant has a feature to turn off the warning messages. 

'javac' does. That's more relevant because Ant isn't the one issuing the warnings.

"-Xlint:-rawtypes"

This is bad because it hides the problem without fixing it.

You should familiarize yourself with the Java tools.

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html#xlintwarnings

> 
> This is my ant script to build:
> 	<target name="compile" depends="prepare">
> 		<javac srcdir="${src.dir}" destdir="${build.dir}" compiler="modern" fork="yes" debug="on">
> 			<classpath refid="project.classpath"/>
> 			<compilerarg value="-Xlint"/>

"-Xlint:what"?

All you do with that option is: "Enable all recommended warnings. In this release, enabling all available warnings is recommended."

As mentioned in the documentation for "javac", which you should study.

> 		</javac>
> 	</target>
> 
> To be honest, I do not know the feature "-Xlint" etc.

To be honest, shame on you.

RTFM.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13386

On Wed, 4 Apr 2012 06:29:12 -0700 (PDT), zyng <xsli2@yahoo.com> wrote,
quoted or indirectly quoted someone who said :

>When I run ant, a lot of warnings are printed out on the screen. It is very=
> daunting. It makes new people to feel, as first response, this is broken. =
>But actually, the build is successful. I pasted a few warning messages belo=
>w. In our real code, there are hundreds of them.

Read up on javac.exe.  You can give it an option to turn them off.
see http://mindprod.com/jgloss/javacexe.html

I am not going to tell you what it is because is unwise to ignore
those warning messages.

I use a "lint" program in IntelliJ to find even pickier warnings.
These are often indicative of bugs.  Fixing them helps prevent bugs,
in particular generifying your code to specify just what you intend to
go inside each collection. See
http://mindprod.com/jgloss/generics.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

[toc] | [prev] | [next] | [standalone]

#13405

Roedy Green wrote:
> zyng quoted or indirectly quoted someone who said :
>> When I run ant, a lot of warnings are printed out on the screen. It is very 
>> daunting. It makes new people to feel, as first response, this is broken.  
>> But actually, the build is successful. I pasted a few warning messages below.
>> In our real code, there are hundreds of them.
> 
> Read up on javac.exe.  You can give it an option to turn them off.
> see http://mindprod.com/jgloss/javacexe.html
> 
> I am not going to tell you what it is because is unwise to ignore
> those warning messages.

Too late. As you have read earlier, I already let the "-Xlint:-rawtypes" cat out of the bag.

Oops! Oh, no, I did it again.

> I use a "lint" program in IntelliJ to find even pickier warnings.
> These are often indicative of bugs.  Fixing them helps prevent bugs,
> in particular generifying your code to specify just what you intend to
> go inside each collection. See
> http://mindprod.com/jgloss/generics.html

Go, go, Findbugs.  Findbugs is great for finding picky warnings.

OP, Roedy is right - fix the generics.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13406

On 4/4/2012 6:24 PM, Lew wrote:
...
> OP, Roedy is right - fix the generics.
>

I'm not sure that is always the best solution.

When generics came out, I tried to convert the program I was working on
to use them, but quickly realized I didn't know enough. I fixed some
simple cases, turned off the warnings so they would not hide other
warnings, and started a side project to read and practice using them.

A few months later, I had learned enough and did a refactoring pass
during which I fixed the generics and re-enabled the related warnings.

That program was under active development. If it had been rarely used
and even more rarely modified, I might have decided that the risks and
costs of doing the generics refactoring pass were greater than the risks
and costs of not doing it, and left the warnings disabled.

Patricia

[toc] | [prev] | [next] | [standalone]

#13407

Patricia Shanahan wrote:
> Lew wrote:
> ...
>> OP, Roedy is right - fix the generics.
>>
>
> I'm not sure that is always the best solution.
>
> When generics came out, I tried to convert the program I was working on
> to use them, but quickly realized I didn't know enough. I fixed some
> simple cases, turned off the warnings so they would not hide other
> warnings, and started a side project to read and practice using them.
>
> A few months later, I had learned enough and did a refactoring pass
> during which I fixed the generics and re-enabled the related warnings.
>
> That program was under active development. If it had been rarely used
> and even more rarely modified, I might have decided that the risks and
> costs of doing the generics refactoring pass were greater than the risks
> and costs of not doing it, and left the warnings disabled.

In the OP's case we're talking about a system that, by his statement, 
"hundreds" of these warning messages. He didn't say what the state of testing 
was for that system, nor much about the code that has the problem other than 
it was "written by different people", but with that degree of warning blast 
there is a high probability of real trouble.

I do not perceive that the OP's understanding is nuanced enough to reliably 
triage warnings that can be suppressed from real trouble. In general, warnings 
represent trouble, and your suggestion to suppress them carries risk. In the 
OP's case, I assess the biggest risk is that the technical debt is far deeper 
than just some raw types. The degree of careless that leads "different people" 
to ignore warnings until there are hundreds of them bodes ill indeed for the 
OP's project.

It's one thing to ignore warnings you inherit from earlier programmers, but 
that doesn't excuse the earlier programmers or solve the problem.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#13418

On 4/4/12 7:39 PM, Lew wrote:
> Patricia Shanahan wrote:
>> Lew wrote:
>> ...
>>> OP, Roedy is right - fix the generics.
>>>
>>
>> I'm not sure that is always the best solution.
>>
>> When generics came out, I tried to convert the program I was working on
>> to use them, but quickly realized I didn't know enough. I fixed some
>> simple cases, turned off the warnings so they would not hide other
>> warnings, and started a side project to read and practice using them.
>>
>> A few months later, I had learned enough and did a refactoring pass
>> during which I fixed the generics and re-enabled the related warnings.
>>
>> That program was under active development. If it had been rarely used
>> and even more rarely modified, I might have decided that the risks and
>> costs of doing the generics refactoring pass were greater than the risks
>> and costs of not doing it, and left the warnings disabled.
>
> In the OP's case we're talking about a system that, by his statement,
> "hundreds" of these warning messages. He didn't say what the state of
> testing was for that system, nor much about the code that has the
> problem other than it was "written by different people", but with that
> degree of warning blast there is a high probability of real trouble.
>
> I do not perceive that the OP's understanding is nuanced enough to
> reliably triage warnings that can be suppressed from real trouble. In
> general, warnings represent trouble, and your suggestion to suppress
> them carries risk. In the OP's case, I assess the biggest risk is that
> the technical debt is far deeper than just some raw types. The degree of
> careless that leads "different people" to ignore warnings until there
> are hundreds of them bodes ill indeed for the OP's project.
Well, it could also be that the program was originally written for Java 
1.4. These types of warnings didn't happen in 1.4 because there was no 
such thing as raw vs generic types.
>
> It's one thing to ignore warnings you inherit from earlier programmers,
> but that doesn't excuse the earlier programmers or solve the problem.
True.  Often if I'm working in a source file that has a yellow rash 
(warnings show up yellow in my IDE editor), I will spend some time 
creating or verifying the Unit tests, and then clean up the warnings. 
Even if that source file is "owned" by some other group.

This approach of course depends on the culture in your shop, and should 
be taken with care and tact.

[toc] | [prev] | [next] | [standalone]

#13421

Daniel Pitts wrote:
> Lew wrote:
>> In the OP's case we're talking about a system that, by his statement,
>> "hundreds" of these warning messages. He didn't say what the state of
>> testing was for that system, nor much about the code that has the
>> problem other than it was "written by different people", but with that
>> degree of warning blast there is a high probability of real trouble.
>>
>> I do not perceive that the OP's understanding is nuanced enough to
>> reliably triage warnings that can be suppressed from real trouble. In
>> general, warnings represent trouble, and your suggestion to suppress
>> them carries risk. In the OP's case, I assess the biggest risk is that
>> the technical debt is far deeper than just some raw types. The degree of
>> careless that leads "different people" to ignore warnings until there
>> are hundreds of them bodes ill indeed for the OP's project.

> Well, it could also be that the program was originally written for Java 
> 1.4. These types of warnings didn't happen in 1.4 because there was no 
> such thing as raw vs generic types.

It *could* be, but then Java 5 has been out for seven and a half years now. That's a very long type to carry that technical debt. Generics were introduced for a reason, so my comments stand. The OP has a real problem, and hiding it is not the right approach. "They developed it for Java 1.4 eight years ago" is not even a pitiful excuse. Java 5 is already obsolete, and Java 6 is not far behind. Move forward or die.

>> It's one thing to ignore warnings you inherit from earlier programmers,
>> but that doesn't excuse the earlier programmers or solve the problem.

> True.  Often if I'm working in a source file that has a yellow rash 
> (warnings show up yellow in my IDE editor), I will spend some time 
> creating or verifying the Unit tests, and then clean up the warnings. 
> Even if that source file is "owned" by some other group.
> 
> This approach of course depends on the culture in your shop, and should 
> be taken with care and tact.

But leaving them alone in the name of "care and tact" is like lending a heroin addict money because you don't want to offend them. Sure, sometimes you will choose to do that, but don't pretend it solves anything.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13429

On 4/5/2012 2:42 PM, Lew wrote:
> Daniel Pitts wrote:
>> Lew wrote:
>>> In the OP's case we're talking about a system that, by his statement,
>>> "hundreds" of these warning messages. He didn't say what the state of
>>> testing was for that system, nor much about the code that has the
>>> problem other than it was "written by different people", but with that
>>> degree of warning blast there is a high probability of real trouble.
>>>
>>> I do not perceive that the OP's understanding is nuanced enough to
>>> reliably triage warnings that can be suppressed from real trouble. In
>>> general, warnings represent trouble, and your suggestion to suppress
>>> them carries risk. In the OP's case, I assess the biggest risk is that
>>> the technical debt is far deeper than just some raw types. The degree of
>>> careless that leads "different people" to ignore warnings until there
>>> are hundreds of them bodes ill indeed for the OP's project.
>
>> Well, it could also be that the program was originally written for Java
>> 1.4. These types of warnings didn't happen in 1.4 because there was no
>> such thing as raw vs generic types.
>
> It *could* be, but then Java 5 has been out for seven and a half years now. That's a very long type to carry that technical debt. Generics were introduced for a reason, so my comments stand. The OP has a real problem, and hiding it is not the right approach. "They developed it for Java 1.4 eight years ago" is not even a pitiful excuse. Java 5 is already obsolete, and Java 6 is not far behind. Move forward or die.

It is not technical debt.

Technical debt is when the code was not good when written.

Here something externally changed.

And getting funding to lift ones code to a newer version of
platform without providing any new value is typical very
difficult.

Arne

[toc] | [prev] | [next] | [standalone]

#13431

On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>> It *could* be, but then Java 5 has been out for seven and a half
 years now. That's a very long type to carry that technical debt.
Generics were introduced for a reason, so my comments stand. The OP
has a real problem, and hiding it is not the right approach. "They
developed it for Java 1.4 eight years ago" is not even a pitiful
excuse. Java 5 is already obsolete, and Java 6 is not far behind. Move
forward or die.

>It is not technical debt.
>
>Technical debt is when the code was not good when written.

     I think you are making a useless distinction here.  Something got
changed that caused technical debt.

>Here something externally changed.

     Internally, the version of Java used changed.  Had that not
changed, there would be no problem.

>And getting funding to lift ones code to a newer version of
>platform without providing any new value is typical very
>difficult.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13507

On 4/5/2012 10:35 PM, Gene Wirchenko wrote:
> On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj<arne@vajhoej.dk>
>> It is not technical debt.
>>
>> Technical debt is when the code was not good when written.
>
>       I think you are making a useless distinction here.  Something got
> changed that caused technical debt.

Not per standard definitions.

http://en.wikipedia.org/wiki/Technical_debt

<quote>
Technical debt (also known as design debt or code debt) is a neologistic 
metaphor referring to the eventual consequences of poor software 
architecture and software development within a codebase. </quote>

http://martinfowler.com/bliki/TechnicalDebt.html

<quote>
Technical Debt is a wonderful metaphor developed by Ward Cunningham to 
help us think about this problem. In this metaphor, doing things the 
quick and dirty way sets us up with a technical debt, which is similar 
to a financial debt.
</quote>

>> Here something externally changed.
>
>       Internally, the version of Java used changed.  Had that not
> changed, there would be no problem.

True.

But upgrading compiler/runtime does not really qualify as
"poor software architecture and software development" or
"quick and dirty way".

Arne

[toc] | [prev] | [next] | [standalone]

#13512

On Thu, 12 Apr 2012 20:27:28 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 4/5/2012 10:35 PM, Gene Wirchenko wrote:
>> On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj<arne@vajhoej.dk>
>>> It is not technical debt.
>>>
>>> Technical debt is when the code was not good when written.
>>
>>       I think you are making a useless distinction here.  Something got
>> changed that caused technical debt.
>
>Not per standard definitions.
>
>http://en.wikipedia.org/wiki/Technical_debt

     In the second to last paragraph, the above has "Activities that
might be postponed include ... tackling compiler ... warnings."

><quote>
>Technical debt (also known as design debt or code debt) is a neologistic 
>metaphor referring to the eventual consequences of poor software 
>architecture and software development within a codebase. </quote>

     And changing the compiler is not part of software development?

>http://martinfowler.com/bliki/TechnicalDebt.html
>
><quote>
>Technical Debt is a wonderful metaphor developed by Ward Cunningham to 
>help us think about this problem. In this metaphor, doing things the 
>quick and dirty way sets us up with a technical debt, which is similar 
>to a financial debt.
></quote>

     Q&D such as changing compilers without testing everything.

>>> Here something externally changed.
>>
>>       Internally, the version of Java used changed.  Had that not
>> changed, there would be no problem.
>
>True.
>
>But upgrading compiler/runtime does not really qualify as
>"poor software architecture and software development" or
>"quick and dirty way".

     It sure can.

     Do you port the code to the new compiler, or do you just hope?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13540

On 4/12/2012 10:29 PM, Gene Wirchenko wrote:
> On Thu, 12 Apr 2012 20:27:28 -0400, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>
>> On 4/5/2012 10:35 PM, Gene Wirchenko wrote:
>>> On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj<arne@vajhoej.dk>
>>>> It is not technical debt.
>>>>
>>>> Technical debt is when the code was not good when written.
>>>
>>>        I think you are making a useless distinction here.  Something got
>>> changed that caused technical debt.
>>
>> Not per standard definitions.
>>
>> http://en.wikipedia.org/wiki/Technical_debt
>
>       In the second to last paragraph, the above has "Activities that
> might be postponed include ... tackling compiler ... warnings."

Yes.

But the context is still when the code is written, so it does not
apply here.

>> <quote>
>> Technical debt (also known as design debt or code debt) is a neologistic
>> metaphor referring to the eventual consequences of poor software
>> architecture and software development within a codebase.</quote>
>
>       And changing the compiler is not part of software development?
>
>> http://martinfowler.com/bliki/TechnicalDebt.html
>>
>> <quote>
>> Technical Debt is a wonderful metaphor developed by Ward Cunningham to
>> help us think about this problem. In this metaphor, doing things the
>> quick and dirty way sets us up with a technical debt, which is similar
>> to a financial debt.
>> </quote>
>
>       Q&D such as changing compilers without testing everything.

They may have tested everything perfectly.

But they still got a problem.

>>>> Here something externally changed.
>>>
>>>        Internally, the version of Java used changed.  Had that not
>>> changed, there would be no problem.
>>
>> True.
>>
>> But upgrading compiler/runtime does not really qualify as
>> "poor software architecture and software development" or
>> "quick and dirty way".
>
>       It sure can.
>
>       Do you port the code to the new compiler, or do you just hope?

????

Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?

Arne

[toc] | [prev] | [next] | [standalone]

#13548

Arne Vajhøj wrote:
> Are you claiming that it is poor software architecture/development
> to write code that does not have a single flaw at time of being written
> but 5 or 10 years later give warnings or errors with a new Java
> version?

I don't know if he is, but I am.

The point was made upthread that when you introduce a new Java version, you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.

The team introduces a change - let's upgrade to Java 5 (already out of date, BTW). That change introduces regressions. The team ignores the regressions. How can anyone make the case that that's good software development?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13549

On 4/14/2012 3:53 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Are you claiming that it is poor software architecture/development
>> to write code that does not have a single flaw at time of being written
>> but 5 or 10 years later give warnings or errors with a new Java
>> version?
>
> I don't know if he is, but I am.

I think you should read it once more.

I don't think you really consider programmers not able to predict the
future to be poor programmers.

> The point was made upthread that when you introduce a new Java version, you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.

Nobody is denying that.

We are discussing whether the code comes with technical debt or not.

It does not.

Unless one require developers to be able to predict the future.

Which I do not.

Arne

[toc] | [prev] | [next] | [standalone]

#13550

Arne Vajhøj wrote:
> Lew wrote:
>> Arne Vajhøj wrote:
>>> Are you claiming that it is poor software architecture/development
>>> to write code that does not have a single flaw at time of being written
>>> but 5 or 10 years later give warnings or errors with a new Java
>>> version?
>>
>> I don't know if he is, but I am.
>
> I think you should read it once more.
> 
> I don't think you really consider programmers not able to predict the
> future to be poor programmers.
> 
> > The point was made upthread that when you introduce a new Java version, you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.
> 
> Nobody is denying that.
> 
> We are discussing whether the code comes with technical debt or not.

It does, once the compiler has been changed and the concomitant warnings ignored.

The question isn't whether it was technical debt in 1993 but whether it's technical debt today. Your argument only presents a case that it wasn't technical debt in 1993.

> It does not.
> 
> Unless one require developers to be able to predict the future.
> 
> Which I do not.

At no point do I require anyone to predict the future, only observe the present. You're the one attempting to reframe the discussion to one of prognostication. It is not a valid restatement of the issue to do so.

At the point when the OP's project converted to Java 5 or later, and ignored the generics warnings, those warnings became technical debt. No crystal ball needed; this is historic.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13551

On 4/14/2012 4:37 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arne Vajhøj wrote:
>>>> Are you claiming that it is poor software architecture/development
>>>> to write code that does not have a single flaw at time of being written
>>>> but 5 or 10 years later give warnings or errors with a new Java
>>>> version?
>>>
>>> I don't know if he is, but I am.
>>
>> I think you should read it once more.
>>
>> I don't think you really consider programmers not able to predict the
>> future to be poor programmers.
>>
>>> The point was made upthread that when you introduce a new Java version, you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.
>>
>> Nobody is denying that.
>>
>> We are discussing whether the code comes with technical debt or not.
>
> It does, once the compiler has been changed and the concomitant warnings ignored.
>
> The question isn't whether it was technical debt in 1993 but whether it's technical debt today. Your argument only presents a case that it wasn't technical debt in 1993.

Actually not.

You wrote:

#It *could* be, but then Java 5 has been out for seven and a half years
#now. That's a very long type to carry that technical debt.

So you claimed that it has been a technical debt since 2004.

I gave references (Wikipedia and Fowler) that technical debt is code
that was bad when written.

Either you use a non standard meaning of technical debt
or you want the original developers to have been able to
foresee the future.

The original poster has not expressed that he want not to
fix the warnings nor have anyone adviced him to do so.

Nobody is arguing that it would become technical debt if
it ended up so. But it seems not particular relevant
for whether the code has had a technical debt since 2004.

And given that Java 1.0 was released for GA in January 1996,
then I also fail to see any relevance of 1993.

>> It does not.
>>
>> Unless one require developers to be able to predict the future.
>>
>> Which I do not.
>
> At no point do I require anyone to predict the future, only observe the present. You're the one attempting to reframe the discussion to one of prognostication. It is not a valid restatement of the issue to do so.
>
> At the point when the OP's project converted to Java 5 or later, and ignored the generics warnings, those warnings became technical debt. No crystal ball needed; this is historic.

There are two big problems with that argument.

1) The OP never stated anything about ignoring messages. That
    is something you just have made up.

2) Your reply was to Daniel Pitt stating that the code could have been
    written for Java 1.4.

Arne

[toc] | [prev] | [next] | [standalone]

#13552

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> I gave references (Wikipedia and Fowler) that technical debt is code
> that was bad when written.
> 
> Either you use a non standard meaning of technical debt
> or you want the original developers to have been able to
> foresee the future.

I have to say I must agree with Lew's use of the term here. To my ear,
it doesn't make sense to exclude issues arising from the datedness of
the codebase from the concept "technical debt." 

Issues such as workarounds for old bugs in compilers or libraries, the
use of outmoded software idioms, failure to adhere to today's best
practices, roll-your-own implementations of functionality that has
since been covered by mature, widely adopted libraries -- once you
bring the code back out into the open and blow the dust off it, these
all affect the software development in the same way as "ordinary"
technical debt.

I don't agree with Lew's view that it's necessarily bad software
development to let sleeping dogs lie. It comes down to a cost /
benefit calculation -- the cost of up-to-dateing a non-trivial
software project can be significant and the benefits might not be. It
depends on the size and age of the project and on why you're dragging
it back into the light.

(For particularly large projects, it might not going to be _possible_
to keep the entire project up-to-date with current best-practices and
idioms. It'll be like painting a major bridge -- by the time you've
painted your way to the far side, it'll be time to start on the near
side again.)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#13553

On 12-04-15 03:25 AM, Leif Roar Moldskred wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I gave references (Wikipedia and Fowler) that technical debt is code
>> that was bad when written.
>>
>> Either you use a non standard meaning of technical debt
>> or you want the original developers to have been able to
>> foresee the future.
> 
> I have to say I must agree with Lew's use of the term here. To my ear,
> it doesn't make sense to exclude issues arising from the datedness of
> the codebase from the concept "technical debt." 
> 
> Issues such as workarounds for old bugs in compilers or libraries, the
> use of outmoded software idioms, failure to adhere to today's best
> practices, roll-your-own implementations of functionality that has
> since been covered by mature, widely adopted libraries -- once you
> bring the code back out into the open and blow the dust off it, these
> all affect the software development in the same way as "ordinary"
> technical debt.
> 
> I don't agree with Lew's view that it's necessarily bad software
> development to let sleeping dogs lie. It comes down to a cost /
> benefit calculation -- the cost of up-to-dateing a non-trivial
> software project can be significant and the benefits might not be. It
> depends on the size and age of the project and on why you're dragging
> it back into the light.
> 
> (For particularly large projects, it might not going to be _possible_
> to keep the entire project up-to-date with current best-practices and
> idioms. It'll be like painting a major bridge -- by the time you've
> painted your way to the far side, it'll be time to start on the near
> side again.)
> 

Let's cast blame where blame is due.

The way I see it, there are several forms of technical debt involved
here, with a codebase X written in language Lang1.0 with libraries
Libs1.0, that transitions across language and API changes to language
Lang2.0 and libraries Libs2.0.

There is technical debt associated with the application, but there is
also technical debt associated with the language and official libraries.

If the language originally caused you to write your own libraries to do
a bunch of things, the ongoing maintenance associated with those
libraries is actually technical debt that is _primarily_ down to the
people who wrote the language and the official libraries. Assuming good
practices in writing those custom libraries with the available tools,
there is only a small fraction of technical debt at that stage that is
down to the application developers.

When the language and API transition occurs to Lang2.0 and Libs2.0, the
language and official library writers have actually paid down a portion
of *their* technical debt. But this only helps new work that avails
itself of the new stuff.

The technical debt in the _existing application_, that which is
specifically incurred by the language and official library writers, will
never be paid down by those people. It's up to other people to pay that off.

The application developers - that means us - don't actually care who
incurred the technical debt. Anyone who has ever worked with an early
language or early APIs or early tools surely can appreciate that there's
a load of debt being incurred by use of all of those - and it's not
*our* fault. We _know_ that there will be upgrades in the future, and
we'll be able to rewrite and re-configure to reduce the debt.

The point being, overall technical debt at any point is a combination of
debt incurred by every nut and bolt, and you yourself potentially caused
little of it. You, however, will likely do more than your fair share of
the work to pay it down.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#13559

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
 
> The point being, overall technical debt at any point is a combination of
> debt incurred by every nut and bolt, and you yourself potentially caused
> little of it. You, however, will likely do more than your fair share of
> the work to pay it down.

Absolutely.

On a tangential note, I think that the current practice of online
artifact repositories (as championed by Maven) is going to cause a lot
of Java projects to become practically unmaintable a few years down
the path. 

(I have no confidence that everything that's currently available from
the repository servers, wether local or central, is going to be
available in five or ten years from now. By all means use dependency
management, just, please, check the damned jars in next to the code,
will you?)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web