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.