How to turn off those warning messages during ant build?

Discussion in 'Java' started by zyng, Apr 4, 2012.

  1. zyng

    zyng Guest

    Hi:

    When I run ant, a lot of warnings are printed out on the screen. It is verydaunting. 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.
     
    zyng, Apr 4, 2012
    #1
    1. Advertising

  2. zyng

    Lew Guest

    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
     
    Lew, Apr 4, 2012
    #2
    1. Advertising

  3. zyng

    Roedy Green Guest

    On Wed, 4 Apr 2012 06:29:12 -0700 (PDT), zyng <> 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..
     
    Roedy Green, Apr 4, 2012
    #3
  4. zyng

    Lew Guest

    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
     
    Lew, Apr 5, 2012
    #4
  5. zyng

    Lew Guest

    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
     
    Lew, Apr 5, 2012
    #5
  6. zyng

    Daniel Pitts Guest

    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.
     
    Daniel Pitts, Apr 5, 2012
    #6
  7. zyng

    Lew Guest

    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 youwill choose to do that, but don't pretend it solves anything.

    --
    Lew
     
    Lew, Apr 5, 2012
    #7
  8. zyng

    Arne Vajhøj Guest

    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
     
    Arne Vajhøj, Apr 6, 2012
    #8
  9. On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj <>
    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
     
    Gene Wirchenko, Apr 6, 2012
    #9
  10. zyng

    Eric Sosman Guest

    On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    > On 4/5/2012 2:42 PM, Lew wrote:
    >> [...] "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.


    So the debt is incurred by Java itself, not by the code written
    in Java? Okay, then: It's not a technical debt, it's a technical tax.

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


    True, and rightly so. Any rewrite, even one that's 95% mechanical,
    is guaranteed to introduce new errors that will need to be found and
    fixed and patched and apologized for. To disturb the (mature, tested,
    trusted) code, you need a better reason than "Fashions have changed."

    --
    Eric Sosman
    d
     
    Eric Sosman, Apr 6, 2012
    #10
  11. On 12-04-05 11:41 PM, Eric Sosman wrote:
    > On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >> On 4/5/2012 2:42 PM, Lew wrote:
    >>> [...] "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.

    >
    > So the debt is incurred by Java itself, not by the code written
    > in Java? Okay, then: It's not a technical debt, it's a technical tax.
    >
    >> And getting funding to lift ones code to a newer version of
    >> platform without providing any new value is typical very
    >> difficult.

    >
    > True, and rightly so. Any rewrite, even one that's 95% mechanical,
    > is guaranteed to introduce new errors that will need to be found and
    > fixed and patched and apologized for. To disturb the (mature, tested,
    > trusted) code, you need a better reason than "Fashions have changed."
    >

    Well, it's not just "fashions have changed", nor in answer to Arne's
    point is it the case that there is no new value. The new value that I'd
    expect to get from a newer version of Java, and the message I'd want to
    push to business, is that the maintainability and adaptability of the
    codebase has now improved.

    Just last year I worked on a project where I was compelled to write new
    code in Java 1.3. With java.lang.String, for example, the extra amount
    of error-prone code I had to write to do some string manipulations was
    jarring, because of missing methods that showed up only in 1.4 or 1.5.

    "Mature, tested, trusted" in many cases really means that you've got
    known problems that have bandaid fixes, carefully worked-out data fixes,
    and established workarounds for problems. That's not a state of affairs,
    except with an app that is due to be replaced soon, that I think I'd
    want to tolerate: any upgrade of the language that shakes the tree and
    forces improvements to the program is, I contend, a good thing.

    AHS
    --
    A fly was very close to being called a "land," cause that's what they do
    half the time.
    -- Mitch Hedberg
     
    Arved Sandstrom, Apr 6, 2012
    #11
  12. zyng

    Eric Sosman Guest

    On 4/6/2012 6:53 PM, Arved Sandstrom wrote:
    > On 12-04-05 11:41 PM, Eric Sosman wrote:
    >> On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >>> On 4/5/2012 2:42 PM, Lew wrote:
    >>>> [...] "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.

    >>
    >> So the debt is incurred by Java itself, not by the code written
    >> in Java? Okay, then: It's not a technical debt, it's a technical tax.
    >>
    >>> And getting funding to lift ones code to a newer version of
    >>> platform without providing any new value is typical very
    >>> difficult.

    >>
    >> True, and rightly so. Any rewrite, even one that's 95% mechanical,
    >> is guaranteed to introduce new errors that will need to be found and
    >> fixed and patched and apologized for. To disturb the (mature, tested,
    >> trusted) code, you need a better reason than "Fashions have changed."
    >>

    > Well, it's not just "fashions have changed", nor in answer to Arne's
    > point is it the case that there is no new value. The new value that I'd
    > expect to get from a newer version of Java, and the message I'd want to
    > push to business, is that the maintainability and adaptability of the
    > codebase has now improved.


    In the specific case of generics (the root of the O.P.'s issue),
    the benefit is that the compiler can now inform you of some errors
    that would not have been detected until run time. Earlier detection
    typically leads to earlier fixing with less effort and expense, and
    that's all to the good.

    But the code that troubles the O.P. was (presumably) written and
    tested and debugged in the pre-generics days. If generics had been
    available the testing and debugging might have been easier, but hard
    though they might have been they've been done. The writers of the
    code were the early adopters who paid top dollar for something that
    has since come down in price; is that any reason to scorn them? Or,
    for that matter, is it any reason to stop using what they built?

    Analogy: You've decided to build an old-fashioned underground
    barbecue pit in your back yard, a full-scale, brick-lined beauty
    in which you can cook three full-grown alligators simultaneously.
    The first requirement is a hole in the ground, three meters long
    by two meters across by one meter deep. On a lovely bright morning
    you grab your shovel and start digging.

    It's hard work. Six cubic meters of earth is not child's play,
    and the sun is hot, and the mosquitoes are pestilent, and the beer
    is warm and flat. But by day's end you've got a perfectly beautiful
    hole, a big pile of dirt, and a sense of accomplishment. And then
    some guy with a backhoe comes along and says "Geez, I coulda done
    that for you in ten easy minutes."

    Do you say "Thanks, but the job's done. Wish I'd known you and
    your machine were available, but them's the breaks"?

    Or do you say "Can you come back later? I've got to shovel the
    dirt back into the hole so you can dig it out for me"?

    > Just last year I worked on a project where I was compelled to write new
    > code in Java 1.3. With java.lang.String, for example, the extra amount
    > of error-prone code I had to write to do some string manipulations was
    > jarring, because of missing methods that showed up only in 1.4 or 1.5.


    It seems to me that there's a difference between "Stone Age String
    lacks methods, so I need to write more code" and "Stone Age Java is
    slow to catch my mistakes, so I find out about them later." In both,
    the outcome is that Baroque Era Java is easier to use, but I think
    the nature of the improvements is difficult to compare meaningfully.

    > "Mature, tested, trusted" in many cases really means that you've got
    > known problems that have bandaid fixes, carefully worked-out data fixes,
    > and established workarounds for problems. That's not a state of affairs,
    > except with an app that is due to be replaced soon, that I think I'd
    > want to tolerate: any upgrade of the language that shakes the tree and
    > forces improvements to the program is, I contend, a good thing.


    Write Thrice, Run Anywhere? ;-)

    --
    Eric Sosman
    d
     
    Eric Sosman, Apr 7, 2012
    #12
  13. zyng

    Arne Vajhøj Guest

    On 4/5/2012 10:35 PM, Gene Wirchenko wrote:
    > On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj<>
    >> 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
     
    Arne Vajhøj, Apr 13, 2012
    #13
  14. zyng

    Arne Vajhøj Guest

    On 4/5/2012 10:41 PM, Eric Sosman wrote:
    > On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >> On 4/5/2012 2:42 PM, Lew wrote:
    >>> [...] "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.

    >
    > So the debt is incurred by Java itself, not by the code written
    > in Java? Okay, then: It's not a technical debt, it's a technical tax.


    You just invented a new term.

    And I like it - with the note that while technical debt is
    a negative thing to have then a technical tax is a good thing
    (ones platform is very much alive).

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

    >
    > True, and rightly so. Any rewrite, even one that's 95% mechanical,
    > is guaranteed to introduce new errors that will need to be found and
    > fixed and patched and apologized for. To disturb the (mature, tested,
    > trusted) code, you need a better reason than "Fashions have changed."


    Yep.

    Arne
     
    Arne Vajhøj, Apr 13, 2012
    #14
  15. zyng

    Arne Vajhøj Guest

    On 4/6/2012 6:53 PM, Arved Sandstrom wrote:
    > On 12-04-05 11:41 PM, Eric Sosman wrote:
    >> On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >>> On 4/5/2012 2:42 PM, Lew wrote:
    >>>> [...] "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.

    >>
    >> So the debt is incurred by Java itself, not by the code written
    >> in Java? Okay, then: It's not a technical debt, it's a technical tax.
    >>
    >>> And getting funding to lift ones code to a newer version of
    >>> platform without providing any new value is typical very
    >>> difficult.

    >>
    >> True, and rightly so. Any rewrite, even one that's 95% mechanical,
    >> is guaranteed to introduce new errors that will need to be found and
    >> fixed and patched and apologized for. To disturb the (mature, tested,
    >> trusted) code, you need a better reason than "Fashions have changed."
    >>

    > Well, it's not just "fashions have changed", nor in answer to Arne's
    > point is it the case that there is no new value. The new value that I'd
    > expect to get from a newer version of Java, and the message I'd want to
    > push to business, is that the maintainability and adaptability of the
    > codebase has now improved.


    That is a classic argument.

    But does it hold water?

    Let us say that you have 100 Java developers maintaining
    a code base in Java 1.4 - how many people would you reduce that to
    if you got it lifted to 1.6? 90? 80? 70? 60?

    > Just last year I worked on a project where I was compelled to write new
    > code in Java 1.3. With java.lang.String, for example, the extra amount
    > of error-prone code I had to write to do some string manipulations was
    > jarring, because of missing methods that showed up only in 1.4 or 1.5.
    >
    > "Mature, tested, trusted" in many cases really means that you've got
    > known problems that have bandaid fixes, carefully worked-out data fixes,
    > and established workarounds for problems. That's not a state of affairs,
    > except with an app that is due to be replaced soon, that I think I'd
    > want to tolerate: any upgrade of the language that shakes the tree and
    > forces improvements to the program is, I contend, a good thing.


    There are good and bad things.

    And then there are things that increase cost and those that
    reduce cost.

    Arne
     
    Arne Vajhøj, Apr 13, 2012
    #15
  16. zyng

    Eric Sosman Guest

    On 4/12/2012 8:29 PM, Arne Vajhøj wrote:
    > On 4/5/2012 10:41 PM, Eric Sosman wrote:
    >> On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >>> On 4/5/2012 2:42 PM, Lew wrote:
    >>>> [...] "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.

    >>
    >> So the debt is incurred by Java itself, not by the code written
    >> in Java? Okay, then: It's not a technical debt, it's a technical tax.

    >
    > You just invented a new term.
    >
    > And I like it - with the note that while technical debt is
    > a negative thing to have then a technical tax is a good thing
    > (ones platform is very much alive).


    In my country, taxes are imposed from without (whatever they
    say about "representation"), are paid grudgingly, and are viewed
    as an unpleasant burden.

    Denmark must be different.

    --
    Eric Sosman
    d
     
    Eric Sosman, Apr 13, 2012
    #16
  17. On Thu, 12 Apr 2012 20:27:28 -0400, Arne Vajhøj <>
    wrote:

    >On 4/5/2012 10:35 PM, Gene Wirchenko wrote:
    >> On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajhøj<>
    >>> 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
     
    Gene Wirchenko, Apr 13, 2012
    #17
  18. On 12-04-12 09:33 PM, Arne Vajhøj wrote:
    > On 4/6/2012 6:53 PM, Arved Sandstrom wrote:
    >> On 12-04-05 11:41 PM, Eric Sosman wrote:
    >>> On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >>>> On 4/5/2012 2:42 PM, Lew wrote:
    >>>>> [...] "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.
    >>>
    >>> So the debt is incurred by Java itself, not by the code written
    >>> in Java? Okay, then: It's not a technical debt, it's a technical tax.
    >>>
    >>>> And getting funding to lift ones code to a newer version of
    >>>> platform without providing any new value is typical very
    >>>> difficult.
    >>>
    >>> True, and rightly so. Any rewrite, even one that's 95% mechanical,
    >>> is guaranteed to introduce new errors that will need to be found and
    >>> fixed and patched and apologized for. To disturb the (mature, tested,
    >>> trusted) code, you need a better reason than "Fashions have changed."
    >>>

    >> Well, it's not just "fashions have changed", nor in answer to Arne's
    >> point is it the case that there is no new value. The new value that I'd
    >> expect to get from a newer version of Java, and the message I'd want to
    >> push to business, is that the maintainability and adaptability of the
    >> codebase has now improved.

    >
    > That is a classic argument.
    >
    > But does it hold water?
    >
    > Let us say that you have 100 Java developers maintaining
    > a code base in Java 1.4 - how many people would you reduce that to
    > if you got it lifted to 1.6? 90? 80? 70? 60?


    That depends on the nature of the work. But let me give you an example:
    let's say that the 1.4 codebase is loaded with low-level concurrency
    constructs. Modules that use this kind of code may be "hands-off, it
    sort of works except when it doesn't. I've worked with plenty of Java
    apps that have this kind of older concurrency code.

    I think there is/was a compelling case to move to 1.5 or 1.6 or 1.7
    simply to avail oneself of the java.util.concurrent stuff. I have
    reworked several subsystems for clients in this manner and I know for a
    fact that it has freed up significant inhouse developer time for more
    useful work. Not only that, but having 1.5 or 1.6 or 1.7 be the new
    organizational standard for a client means that new systems will
    inexorably use java.util.concurrent APIs for concurrency work.
    Developers lead and follow by example: keep 1.4 low-level thread code
    around in apps and it tends to be copied.

    That's just one example.

    >> Just last year I worked on a project where I was compelled to write new
    >> code in Java 1.3. With java.lang.String, for example, the extra amount
    >> of error-prone code I had to write to do some string manipulations was
    >> jarring, because of missing methods that showed up only in 1.4 or 1.5.
    >>
    >> "Mature, tested, trusted" in many cases really means that you've got
    >> known problems that have bandaid fixes, carefully worked-out data fixes,
    >> and established workarounds for problems. That's not a state of affairs,
    >> except with an app that is due to be replaced soon, that I think I'd
    >> want to tolerate: any upgrade of the language that shakes the tree and
    >> forces improvements to the program is, I contend, a good thing.

    >
    > There are good and bad things.
    >
    > And then there are things that increase cost and those that
    > reduce cost.
    >
    > Arne
    >

    I'd leave a 1.4 system be if it was reliable and was never going to be
    modified or extended. But if that was not the case I'd introduce a Java
    version upgrade with the new work.

    AHS
    --
    A fly was very close to being called a "land," cause that's what they do
    half the time.
    -- Mitch Hedberg
     
    Arved Sandstrom, Apr 14, 2012
    #18
  19. zyng

    Arne Vajhøj Guest

    On 4/13/2012 8:16 PM, Arved Sandstrom wrote:
    > On 12-04-12 09:33 PM, Arne Vajhøj wrote:
    >> On 4/6/2012 6:53 PM, Arved Sandstrom wrote:
    >>> On 12-04-05 11:41 PM, Eric Sosman wrote:
    >>>> On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >>>>> On 4/5/2012 2:42 PM, Lew wrote:
    >>>>>> [...] "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.
    >>>>
    >>>> So the debt is incurred by Java itself, not by the code written
    >>>> in Java? Okay, then: It's not a technical debt, it's a technical tax.
    >>>>
    >>>>> And getting funding to lift ones code to a newer version of
    >>>>> platform without providing any new value is typical very
    >>>>> difficult.
    >>>>
    >>>> True, and rightly so. Any rewrite, even one that's 95% mechanical,
    >>>> is guaranteed to introduce new errors that will need to be found and
    >>>> fixed and patched and apologized for. To disturb the (mature, tested,
    >>>> trusted) code, you need a better reason than "Fashions have changed."
    >>>>
    >>> Well, it's not just "fashions have changed", nor in answer to Arne's
    >>> point is it the case that there is no new value. The new value that I'd
    >>> expect to get from a newer version of Java, and the message I'd want to
    >>> push to business, is that the maintainability and adaptability of the
    >>> codebase has now improved.

    >>
    >> That is a classic argument.
    >>
    >> But does it hold water?
    >>
    >> Let us say that you have 100 Java developers maintaining
    >> a code base in Java 1.4 - how many people would you reduce that to
    >> if you got it lifted to 1.6? 90? 80? 70? 60?

    >
    > That depends on the nature of the work. But let me give you an example:
    > let's say that the 1.4 codebase is loaded with low-level concurrency
    > constructs. Modules that use this kind of code may be "hands-off, it
    > sort of works except when it doesn't. I've worked with plenty of Java
    > apps that have this kind of older concurrency code.
    >
    > I think there is/was a compelling case to move to 1.5 or 1.6 or 1.7
    > simply to avail oneself of the java.util.concurrent stuff. I have
    > reworked several subsystems for clients in this manner and I know for a
    > fact that it has freed up significant inhouse developer time for more
    > useful work. Not only that, but having 1.5 or 1.6 or 1.7 be the new
    > organizational standard for a client means that new systems will
    > inexorably use java.util.concurrent APIs for concurrency work.
    > Developers lead and follow by example: keep 1.4 low-level thread code
    > around in apps and it tends to be copied.
    >
    > That's just one example.


    And certainly one of the better examples.

    juc can certainly reduce maintenance cost.

    But if we look at other Java 5 new features: generics, enums,
    new for loop, auto boxing/unboxing, static import, varargs -
    then I do not see the same benefits.

    Arne
     
    Arne Vajhøj, Apr 14, 2012
    #19
  20. zyng

    Arne Vajhøj Guest

    On 4/12/2012 9:28 PM, Eric Sosman wrote:
    > On 4/12/2012 8:29 PM, Arne Vajhøj wrote:
    >> On 4/5/2012 10:41 PM, Eric Sosman wrote:
    >>> On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
    >>>> On 4/5/2012 2:42 PM, Lew wrote:
    >>>>> [...] "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.
    >>>
    >>> So the debt is incurred by Java itself, not by the code written
    >>> in Java? Okay, then: It's not a technical debt, it's a technical tax.

    >>
    >> You just invented a new term.
    >>
    >> And I like it - with the note that while technical debt is
    >> a negative thing to have then a technical tax is a good thing
    >> (ones platform is very much alive).

    >
    > In my country, taxes are imposed from without (whatever they
    > say about "representation"), are paid grudgingly, and are viewed
    > as an unpleasant burden.
    >
    > Denmark must be different.


    Danes generally hate paying taxes as well.

    But that is exactly my point.

    Java developers are more happy about new Java versions with
    new features than citizens are about paying income tax.

    Arne
     
    Arne Vajhøj, Apr 14, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Spencer
    Replies:
    2
    Views:
    458
    Cheung, Jeffrey Jing-Yen
    Jul 8, 2003
  2. BinnuChowdary
    Replies:
    1
    Views:
    542
    Swanand Mokashi
    May 1, 2006
  3. BinnuChowdary
    Replies:
    0
    Views:
    418
    BinnuChowdary
    May 2, 2006
  4. BinnuChowdary
    Replies:
    1
    Views:
    550
    =?UTF-8?B?R8O2cmFuIEFuZGVyc3Nvbg==?=
    May 2, 2006
  5. robert112
    Replies:
    1
    Views:
    443
    Juan T. Llibre
    Apr 26, 2007
Loading...

Share This Page