How to turn off those warning messages during ant build?

[zyng]

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.

 

[Lew]

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.

 

[Roedy Green]

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

 

[Lew]

zyng quoted or indirectly quoted someone who said :

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

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.

 

[Daniel Pitts]

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.

 

[Lew]

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.

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.

 

[Arne Vajhøj]

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

 

[Gene Wirchenko]

[snip]
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

 

[Eric Sosman]

[...] "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."

 

[Arved Sandstrom]

[...] "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

 

[Eric Sosman]

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

 

[Arne Vajhøj]

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.

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]

[...] "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).

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]

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

 

[Eric Sosman]

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.

 

[Gene Wirchenko]

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.

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

 

[Arved Sandstrom]

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.

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

 

[Arne Vajhøj]

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]

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