Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: How to turn off those warning messages during ant build? Date: Fri, 06 Apr 2012 21:35:40 -0400 Organization: A noiseless patient Spider Lines: 89 Message-ID: References: <32649009.2052.1333546152596.JavaMail.geo-discussion-forums@vbsf4> <15429764.10.1333589060953.JavaMail.geo-discussion-forums@pbae2> <10168300.3443.1333651355770.JavaMail.geo-discussion-forums@pbcto7> <4f7e2ee4$0$288$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 7 Apr 2012 01:35:44 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="HSlJAUb3pGXi3i7ZL/HoAw"; logging-data="28992"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195lfoAMJfg7rlJ3o5Artbe" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 In-Reply-To: Cancel-Lock: sha1:SwgjrtBZKYrwR1tFZpg3OIDjXJw= Xref: csiph.com comp.lang.java.programmer: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