Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14322

Re: How to turn off those warning messages during ant build?

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next | Find similar | Unroll thread

Thread

Re: How to turn off those warning messages during ant build? Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:51 -0400

csiph-web