将中型代码库从Java 1.4.2迁移到Java 5的策略

Java 5与Java 4几乎完全向后兼容。通常,唯一能改变你的是 迁移时所做的就是重命名new的任何用法 enum Java 4代码中的关键字。

此处列出了潜在兼容性问题的完整列表:

http://java.sun.com/j2se/1.5.0/compatibility.html

我在迁移代码时喜欢使用的另一个功能是@Override注释。它有助于在重构代码时发现继承问题。

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Override.html

如果你的代码使用线程,新的并发库非常有用。例如,您可以用 ThreadPoolExecutor .

http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#concurrency

我肯定会采取在正常维护期间更改代码时更新代码的方法。除了兼容性问题,我认为没有充分的理由使用Java 5的新功能,除非你已经因为其他原因更改了代码。

仿制药的“病毒性”存在一个非常现实的问题;一旦你开始在架构中的给定层引入它们,你通常希望在上面的层引入它们;下面也是。我发现引入泛型可能最好在完全“垂直”的领域进行。但你不必这么做 全部 垂直的一次。

首先,当迁移是一项艰巨的任务时,请帮自己一个忙,升级到最新版本的Java,即Java 6而不是Java 5。Java 6已经发布了一年半或更长时间,并且已经成熟。没有理由不选择Java 5(imho)。

其次,就像任何软件项目一样,你的目标应该是尽快将一些东西投入生产。因此,您需要确定系统的一部分。越小越好,越不关键越好。

另一件要做的事情就是尝试在Java 6下启动你的应用程序,看看会发生什么。情况可能比你想象的更糟。这可能会好得多。

你可能需要注意的另一件事是,根据它的声音,你的应用程序中会有已经被弃用的jar/库。有些甚至可能与1.4.2之后的Java不兼容。您可能也想将所有这些升级到最新版本。

但也有例外,升级可能会产生深远的影响。我想到了Axis2的Axis1。这些情况需要更仔细的思考。

至于使用了哪些功能。…他们几乎都是。我脑子里想不出任何应该避免的事情。

此外,我刚刚注意到你的项目规模:约20K LOC。这实际上相当小(例如,在过去的3个月里,我自己写了一个大约这个大小的应用程序)。

有问题的情况是,场景很难测试,你可能不会立即发现问题。这需要更加谨慎。

你可能想迁移在从1.4到5的过渡中不起作用的东西(不确定那是什么),但我会对迁移的东西持谨慎态度 清酒

你的代码库中有广泛使用的组件吗?如果是这样的话,就API而言,它们可能是要迁移的候选者(例如,使用泛型等)

就Java 5中广泛使用的内容而言。仿制药很重要,可以让你的生活更轻松。我没有看到自动装箱

20(无评论)kloc应该足够小,可以大幅度插入泛型。显然,请确保您的代码首先在Java SE 5上编译运行。泛型相对容易的一点是,添加它们对语义的影响很小(由于隐式情况,某些重载可能会发生变化- Iterator<char[]> iter; ... System.out.println(iter.next()); 作为我脑海中的一个坏例子)。

在某些情况下,添加泛型会突出代码的概念问题。使用一个 Map 例如具有不相交密钥集的两个映射。 TreeMap Comparator<T> Comparable<T> ).

像增强版和自动拳击这样的东西是非常本地化的,可以零碎地添加。枚举更为罕见,可能需要考虑如何实际使用它们。

我认为你处理这件事的方式不对。你的计划不应该是将所有当前代码更新到Java 1.5,你的计划应该是确保所有当前代码在1.5中的运行与在1.4.2中的运行完全相同,并且所有未来编写的代码都能在1.5中正常工作。

我经历了一些不同大小的代码库的转换。我们的目标始终是确保我们有大量的单元测试,以便我们可以轻松地插入1.5并通过它运行测试。我们实际上遇到了大约10个问题,主要与正则表达式库不支持某些东西或支持不同的东西有关。

然后用1.5编写所有新代码,如果你出于任何原因更改了一个旧类,花一分钟时间实现泛型,但没有理由重构一切。如果你没有做好测试,这对我来说听起来有点危险。