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.