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


Sure - it could make sense.

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

Arne
 
Reply With Quote
 
 
 
 
Arne Vajhj
Guest
Posts: n/a
 
      05-06-2012
On 4/15/2012 10:58 PM, Gene Wirchenko wrote:
> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhj<(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.


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

 
Reply With Quote
 
 
 
 
Arne Vajhj
Guest
Posts: n/a
 
      05-06-2012
On 4/13/2012 9:51 PM, Arved Sandstrom wrote:
> On 12-04-13 10:03 PM, Arne Vajhj wrote:
>> On 4/13/2012 8:16 PM, Arved Sandstrom wrote:
>>> On 12-04-12 09:33 PM, Arne Vajhj 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 Vajhj 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


 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      05-07-2012
On Sat, 05 May 2012 20:47:21 -0400, Arne Vajhj <(E-Mail Removed)>
wrote:

>On 4/15/2012 10:54 PM, Gene Wirchenko wrote:
>> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhj<(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.


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

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      05-07-2012
On Sat, 05 May 2012 20:50:32 -0400, Arne Vajhj <(E-Mail Removed)>
wrote:

>On 4/15/2012 10:58 PM, Gene Wirchenko wrote:
>> On Fri, 13 Apr 2012 21:07:40 -0400, Arne Vajhj<(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.

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