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 2 of 2 — ← Prev page 1 [2]

#14320

On 4/15/2012 2: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."

Sure - it could make sense.

But that is just not how the term has been defined.

Arne

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

#13568

On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>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?

     No, I am stating that if one switches compilers, all bets are
off, and you had better test to make sure that the program still
works.

Sincerely,

Gene Wirchenko

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

#14319

On 4/15/2012 10:54 PM, Gene Wirchenko wrote:
> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>
> [snip]
>
>> 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?
>
>       No, I am stating that if one switches compilers, all bets are
> off, and you had better test to make sure that the program still
> works.

That is rather irrelevant.

The discussion is whether it is technical debt that code
does not compile with future versions of compiler/library.

Arne

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

#14361

On Sat, 05 May 2012 20:47:21 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 4/15/2012 10:54 PM, Gene Wirchenko wrote:
>> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhøj<arne@vajhoej.dk>
>> wrote:
>>
>> [snip]
>>
>>> 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?
>>
>>       No, I am stating that if one switches compilers, all bets are
>> off, and you had better test to make sure that the program still
>> works.
>
>That is rather irrelevant.
>
>The discussion is whether it is technical debt that code
>does not compile with future versions of compiler/library.

     No, it is whether changing to another compiler version can cause
technical debt.  Oh, yes.

Sincerely,

Gene Wirchenko

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

#13569

On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhøj <arne@vajhoej.dk> 
wrote:

[snip]

>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 have seen code that worked with one version of a compiler fail
on the next version, because the parsing had been tightened up.  Code
that had worked for years would suddenly compile with errors.  This
was between different versions of Microsoft Visual FoxPro.

Sincerely,

Gene Wirchenko

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

#14321

On 4/15/2012 10:58 PM, Gene Wirchenko wrote:
> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>
> [snip]
>
>> 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 have seen code that worked with one version of a compiler fail
> on the next version, because the parsing had been tightened up.  Code
> that had worked for years would suddenly compile with errors.  This
> was between different versions of Microsoft Visual FoxPro.

That can happen.

But it is not what is happening here.

OP's code was perfectly valid pre-1.5 Java that gives
warnings due to raw types in 1.5+.

Arne

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

#14362

On Sat, 05 May 2012 20:50:32 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 4/15/2012 10:58 PM, Gene Wirchenko wrote:
>> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhøj<arne@vajhoej.dk>
>> wrote:
>>
>> [snip]
>>
>>> 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 have seen code that worked with one version of a compiler fail
>> on the next version, because the parsing had been tightened up.  Code
>> that had worked for years would suddenly compile with errors.  This
>> was between different versions of Microsoft Visual FoxPro.
>
>That can happen.
>
>But it is not what is happening here.
>
>OP's code was perfectly valid pre-1.5 Java that gives
>warnings due to raw types in 1.5+.

     The Visual FoxPro code in question was perfectly valid by the
rules at the time.  A change in compiler version broke the code.

Sincerely,

Gene Wirchenko

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

#13432

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
esosman@ieee-dot-org.invalid

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

#13443

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

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

#13444

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
esosman@ieee-dot-org.invalid

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

#13509

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

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

#13531

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

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

#13538

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

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

#13541

On 12-04-13 10:03 PM, Arne Vajhøj wrote:
> 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

Nor do I, mostly. I picked java.util.concurrent because it stands out.
Similarly collections enhancements in 1.6. There are other API additions
and enhancements that may be or greater or lesser significance depending
on your interests.

Overall I find that library/API additions and improvements are a much
bigger deal for me than language enhancements. Just from the list above
that you provided, I don't use static import, very rarely use varargs,
use "foreach" because it exists but could easily live without it.
Autoboxing/unboxing: some value in improving readability, provided that
you are aware of the pitfalls. Enums: nice enough but I wouldn't say
they were earthshaking.

Generics: moderate utility. IMO. Same readability problems as what it
replaced, more or less, moved checking to an earlier stage which is
good. But I've written enough code in dynamically-typed languages to
know that I don't typically get hammered by all sorts of runtime errors
anyway, so sometimes the Java approach feels like it solved a problem I
didn't really have. But one's mileage will definitely vary. Don't get me
wrong, I don't think generics are bad, but they are probably by
themselves not a compelling reason to bump up from 1.4 to 1.5 or later.

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]

#14322

On 4/13/2012 9:51 PM, Arved Sandstrom wrote:
> On 12-04-13 10:03 PM, Arne Vajhøj wrote:
>> 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.
>
> Nor do I, mostly. I picked java.util.concurrent because it stands out.
> Similarly collections enhancements in 1.6. There are other API additions
> and enhancements that may be or greater or lesser significance depending
> on your interests.
>
> Overall I find that library/API additions and improvements are a much
> bigger deal for me than language enhancements. Just from the list above
> that you provided, I don't use static import, very rarely use varargs,
> use "foreach" because it exists but could easily live without it.
> Autoboxing/unboxing: some value in improving readability, provided that
> you are aware of the pitfalls. Enums: nice enough but I wouldn't say
> they were earthshaking.
>
> Generics: moderate utility. IMO. Same readability problems as what it
> replaced, more or less, moved checking to an earlier stage which is
> good. But I've written enough code in dynamically-typed languages to
> know that I don't typically get hammered by all sorts of runtime errors
> anyway, so sometimes the Java approach feels like it solved a problem I
> didn't really have. But one's mileage will definitely vary. Don't get me
> wrong, I don't think generics are bad, but they are probably by
> themselves not a compelling reason to bump up from 1.4 to 1.5 or later.

Yes.

Lots of nice features - very few kick ass features.

Arne

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

#13508

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

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

#13511

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
esosman@ieee-dot-org.invalid

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

#13539

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

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

#13425

Daniel Pitts wrote:
> On 4/4/12 7:39 PM, Lew wrote:
...
>> 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.

That was my situation, back when 1.5 came out. My program was
warning-free compiled with 1.4. When I switched to 1.5 it got pages of
warnings. I needed some time to prepare to fix them, and did not want
the generics warnings hiding some other warning.

>>
>> 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.

And with due attention to the real trade-offs between keeping up to date
and staying with a configuration that is working. There are reasons why
Oracle's extended support for 1.4.2 does not end until February of next
year. I wonder how many programs will be switching from 1.4 to a later
JDK during the next few months. We may see this issue again.

Patricia

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web