Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How to turn off those warning messages during ant build?

Reply
Thread Tools

How to turn off those warning messages during ant build?

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-14-2012
On 4/12/2012 10:29 PM, Gene Wirchenko wrote:
> On Thu, 12 Apr 2012 20:27:28 -0400, Arne Vajh°j<(E-Mail Removed)>
> wrote:
>
>> On 4/5/2012 10:35 PM, Gene Wirchenko wrote:
>>> On Thu, 05 Apr 2012 19:46:39 -0400, Arne Vajh°j<(E-Mail Removed)>
>>>> It is not technical debt.
>>>>
>>>> Technical debt is when the code was not good when written.
>>>
>>> I think you are making a useless distinction here. Something got
>>> changed that caused technical debt.

>>
>> Not per standard definitions.
>>
>> http://en.wikipedia.org/wiki/Technical_debt

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


Yes.

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

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

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

>
> Q&D such as changing compilers without testing everything.


They may have tested everything perfectly.

But they still got a problem.

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

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

>
> It sure can.
>
> Do you port the code to the new compiler, or do you just hope?


????

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

Arne

 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-14-2012
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
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      04-14-2012
Arne Vajh°j wrote:
> Are you claiming that it is poor software architecture/development
> to write code that does not have a single flaw at time of being written
> but 5 or 10 years later give warnings or errors with a new Java
> version?


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

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

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

--
Lew

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      04-14-2012
On 4/14/2012 3:53 PM, Lew wrote:
> Arne Vajh°j wrote:
>> Are you claiming that it is poor software architecture/development
>> to write code that does not have a single flaw at time of being written
>> but 5 or 10 years later give warnings or errors with a new Java
>> version?

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


I think you should read it once more.

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

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


Nobody is denying that.

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

It does not.

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

Which I do not.

Arne




 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-14-2012
Arne Vajh°j wrote:
> Lew wrote:
>> Arne Vajh°j wrote:
>>> Are you claiming that it is poor software architecture/development
>>> to write code that does not have a single flaw at time of being written
>>> but 5 or 10 years later give warnings or errors with a new Java
>>> version?

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

>
> I think you should read it once more.
>
> I don't think you really consider programmers not able to predict the
> future to be poor programmers.
>
> > The point was made upthread that when you introduce a new Java version,you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.

>
> Nobody is denying that.
>
> We are discussing whether the code comes with technical debt or not.


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

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

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


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

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

--
Lew

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

>>
>> I think you should read it once more.
>>
>> I don't think you really consider programmers not able to predict the
>> future to be poor programmers.
>>
>>> The point was made upthread that when you introduce a new Java version, you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.

>>
>> Nobody is denying that.
>>
>> We are discussing whether the code comes with technical debt or not.

>
> It does, once the compiler has been changed and the concomitant warnings ignored.
>
> The question isn't whether it was technical debt in 1993 but whether it's technical debt today. Your argument only presents a case that it wasn't technical debt in 1993.


Actually not.

You wrote:

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

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

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

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

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

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

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

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

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


There are two big problems with that argument.

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

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

Arne




 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-15-2012
On 12-04-15 03:25 AM, Leif Roar Moldskred wrote:
> Arne Vajh├Şj <(E-Mail Removed)> wrote:
>>
>> I gave references (Wikipedia and Fowler) that technical debt is code
>> that was bad when written.
>>
>> Either you use a non standard meaning of technical debt
>> or you want the original developers to have been able to
>> foresee the future.

>
> I have to say I must agree with Lew's use of the term here. To my ear,
> it doesn't make sense to exclude issues arising from the datedness of
> the codebase from the concept "technical debt."
>
> Issues such as workarounds for old bugs in compilers or libraries, the
> use of outmoded software idioms, failure to adhere to today's best
> practices, roll-your-own implementations of functionality that has
> since been covered by mature, widely adopted libraries -- once you
> bring the code back out into the open and blow the dust off it, these
> all affect the software development in the same way as "ordinary"
> technical debt.
>
> I don't agree with Lew's view that it's necessarily bad software
> development to let sleeping dogs lie. It comes down to a cost /
> benefit calculation -- the cost of up-to-dateing a non-trivial
> software project can be significant and the benefits might not be. It
> depends on the size and age of the project and on why you're dragging
> it back into the light.
>
> (For particularly large projects, it might not going to be _possible_
> to keep the entire project up-to-date with current best-practices and
> idioms. It'll be like painting a major bridge -- by the time you've
> painted your way to the far side, it'll be time to start on the near
> side again.)
>


Let's cast blame where blame is due.

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

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

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

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

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

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

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

AHS
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-16-2012
On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajh°j <(E-Mail Removed)>
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
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-16-2012
On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajh°j <(E-Mail Removed)>
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-06-2012
On 4/15/2012 10:54 PM, Gene Wirchenko wrote:
> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajh°j<(E-Mail Removed)>
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Re: When running Ant on command line, how to not-show its WARNING messages and only show ERROR message? Roedy Green Java 5 12-13-2011 05:49 PM
Re: When running Ant on command line, how to not-show its WARNING messages and only show ERROR message? John B. Matthews Java 0 12-09-2011 05:19 PM
Warning during generating classes through WSIMPORT & Error during xmlvalidation traveller Java 0 01-08-2008 07:00 AM
Turn off security warning? Captain Infinity Firefox 2 05-23-2005 02:12 PM



Advertisments