Java 1.4 到 Java 6 迁移
我有一些在 Java 1.4 上运行的企业应用程序。它们主要调用数据库上的存储过程、解析 XML 文件（最多几兆大）、从磁盘读取和写入。我们有一个要求，现在必须将这些应用程序迁移到 Java 6（根本不需要进行任何代码更改）。
我的问题：
- 如果我不在 Java 6 下重新编译我的应用程序并只是用它运行它们，它会正常工作吗（我知道它们“应该”）？但如果有人有相反的想法，你能分享一下你的想法吗？
- 更重要的问题是——它会对性能产生影响吗？例如，App 在 1.4 上编译并在 1.6 上运行与 App 在 1.6 上编译并运行。与 1.4 相比，1.6 是否会对相同的旧代码进行任何字节码优化？
非常感谢 js
I have some enterprise apps running on Java 1.4. They mostly invoke Stored Procedures on a DB, Parse XML files (at the most few megs large), read and write from and to disk. We have a requirement where now we have to migrate these apps to Java 6(No code changes to be done at all).
My questions:
- If I don't recompile my apps under Java 6 and just run them with it, will it work fine (I know they 'should')? But if somebody thinks other way round, could you kindly share your thoughts please?
- More important question is - Will it have any performance impact?. As in, App compiled on 1.4 and running on 1.6 vs App compiled and running on 1.6. Is 1.6 going to do any bytecode optimization for the same old piece of code compared to 1.4?
Many Thanks
js
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
用于从 1.4 到 1.6 的构建兼容性
检查枚举变量 - 这是一个新的保留字
For build compatibility from 1.4 to 1.6
Check for enum variables - it is a new reserved word
这并不是真正的编译问题，但您可能会发现在 1.4 和 6 之间将某些第三方组件集成到 JDK 中会出现一些问题。过去我遇到过一些与 XML 和 WS 相关的组件的问题，例如 xerces/xalan。
即使包/命名空间已更改（因此您的现有组件可能会继续被您的代码使用），后台也会发生一些奇怪的自动发现事情，这可能会导致这些组件的不兼容版本发生冲突。
使用认可的类加载器/文件夹可以轻松解决任何问题。
我的建议 - 如果您还没有，请尽快尝试一下，然后看看。
This isn't really a compilation issue, but you may find some problems arise from the integration of certain third-party components into the JDK between 1.4 and 6. I've had issues with some XML- and WS- related components in the past, eg xerces/xalan.
Even where packages/namespaces have changed (and therefore your existing components will probably continue to be used by your code) some odd auto-discovery things happen in the background which can cause incompatible versions of these components to clash.
Using the endorsed classloader/folder may resolve any issues without much effort.
My advice - if you haven't already, try it as soon as you can and see.
优化的不是字节码，字节码格式自 Java 1（！）以来就没有改变。 JVM 将优化那些运行时分析告诉它值得的代码部分，但这些部分是在 JIT 编译的本机代码中。是的，从 4 到 6 的步骤应该会带来更好的性能 - 虚拟机在这 4.5 年里已经取得了长足的进步。
It's not the byte code that gets optimized, the byte code format hasn't changed since Java 1(!). The JVM will optimize those parts of the code where runtime analysis tells it that it is worthwhile, but in the JIT-compiled native code. And yes, the step from 4 to 6 should result in better performance - virtual machines have come a long way in those 4.5 years.