Re: Checked Exception loophole
Daniel Pitts wrote:
Perhaps with the projects you have, buts where I work we have several
projects stuck in Java 1.4, because upgrading is too "expensive" in
man power. It may be true for "smaller" projects, but projects that
have high cost for regression bugs can't rely on upgrades not breaking
things. Or maybe the company I work for is just paranoid :-)
Arne Vajh??j wrote:
You always test if you make any changes, so you always has the cost
of retesting when upgrading.
It does not prove that backwards compatibility is a myth. Even
if there had been zero upgrade problems from 1.0 to current, then
test would still be required.
Where I work I was part of a two-man team that upgraded a million-plus-line
project, comprising some 287 individual Eclipse projects, from Java 1.3 to
Java 5. It took us only a couple of man-days to accommodate the JVM changes,
about three weeks to upgrade to the later version of the Eclipse-based IDE.
Most of that time was discovery of what the IDE meta-files needed to maintain
project integrity, and running scripts to change them /en masse/.
The Java language changes were negligible - we had to replace a couple of
packages (from third parties) that used "enum." in the package hierarchy in a
couple of projects.
The unit tests and integration tests were already in place before the
conversion. The same tests were used to validate the transfer. They, too,
transferred to Java 5 without pain.
This was a major multi-million dollar project. Two people. A couple of
weeks. There was one issue due to the Apache commons-lang project dependency
on having a constant reference initialize a class. This behavior, never
correct according to the JLS, no longer works in Java 5 due to optimizations
in the constant pool. This issue is fixed with a workaround in the few places
where we relied on that behavior.
This proves two points, at least. One is Daniel's, that no change is absent
risk, and one should not just jump into Java 5 blindly. The other is Arne's,
which is that backwards compatibility is incredibly high, breaking only at
well-defined and rarely-used points, one of which was an illegal dependency to
start with. In a place that has testing as part of its project plan already,
the manpower to transfer even quite a large project like ours is really very low.
--
Lew