将 Java 5/6 功能向后移植到 Java 1.4？
直到 2010 年底，我们都坚持使用 Java2SE v1.4。这确实很糟糕，但我们无能为力。 我们现在必须有哪些选择来使用一些新功能？ 我可以想到几种方法，例如
更改字节码，例如使用Retrotranslator或Retroweaver。
库的向后移植，例如并发向后移植，但这对泛型没有帮助。
模拟 Java 5 功能，例如检查集合、带有辅助方法的 Varargs 等。
模拟 Java 5通过预编译更改源代码，在最终编译之前剥离所有 1.5 内容，例如使用 Declawer 可以做到这一点。< /p>
我最感兴趣的是在生产环境中使用 Weblogic 和“真实”的东西获得的非常积极的体验。
We are stuck with Java2SE v1.4 till the end of 2010. That's really nasty, but we can't help it. What options do we have to use some of the new features already now? I can think of several ways like
changing the bytecode, e.g. using Retrotranslator or Retroweaver.
backport of libraries, e.g. Concurrent Backport, but this does not help for generics.
emulation of Java 5 features, e.g. checked Collections, Varargs with helper methods, etc.
changing source code by precompilation, stripping all 1.5 stuff before final compilation, e.g. using Declawer can do this.
I am most interested in very positive experience with it in production environments using Weblogic and "real" stuff.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
感谢您的回答。 这是所有相关答案和我自己的研究的摘要。
更改字节码：Retros
这是由 "retro"-tools 完成的：Retrotranslator、Retroweaver 和 < a href="http://www.jboss.org/community/docs/DOC-10738" rel="nofollow noreferrer">JBossRetro。 Retrotranslator似乎是最成熟的
以及它们的活跃工具。 这些工具扫描所有类并更改字节码以删除 Java 5 和 6 功能。 支持许多 Java5 功能，其中一些
通过使用第 3 方向后移植库。 此选项最受欢迎，并且有一些用户的积极反馈。 实验表明它的工作原理是
预期的。 请参阅 developerworks 的简短概述。
优点：您可以完全使用 Java 5 进行开发、构建模块和所有类型的 JAR。 最后，您只需将所有类转换为 Java 1.4 并打包您的 EAR。
这可以通过 Retrotranslator 的 Maven 集成 (
org.codehaus.mojo:retrotranslator-maven-plugin) 轻松完成。缺点：保守的环境不允许部署更改后的字节码。 任何编码员都看不到回溯步骤的结果，并且无法获得批准。
第二个问题是恐惧：可能存在一些神秘的生产问题，而追溯代码是另一个可能受到指责的步骤。 应用服务器供应商
可能会因字节码更改而拒绝帮助。 因此没有人愿意承担在生产中使用它的责任。 因为这是一个政治问题而非技术问题
问题，所以我看不到解决办法。 这发生在我们身上，所以我正在寻找更多选择:-(
将 Java5 编译为 Java 1.4：jsr14
有一个不受支持的选项，
javac -source 1.5 and -target jsr14，它将 Java5 源代码编译为有效的 Java 1.4 字节码。 大多数功能如无论如何，可变参数或扩展 for 循环都会由编译器进行翻译。 泛型和注释被剥离。 不支持枚举，我不知道
关于自动装箱，因为
valueOf方法主要是在 Java5 中引入的。缺点：只翻译字节码，库的使用没有改变。 因此，您必须小心不要使用 Java5 特定的 API（但可以使用 Backports）。
此外，您必须同时构建所有模块，因为在开发时您可能需要具有通用和注释信息的 Java5 代码。
因此，您必须从头开始构建整个项目才能进行 Java 1.4 生产。
将源代码更改回 Java 1.4：Declawer
正如相关问题中的回答，是 Declawer，编译器扩展，适用于泛型和可变参数，但不适用于增强的 for 循环或
自动装箱。 生成的源代码“有点时髦，但还不错”。
Pro：生成的源可用并且可以查看。 在最坏的情况下，可以在此源中进行修复。 没有“魔法”，因为来源
是有效的 Java。 有些人甚至使用JAD（Java反编译器）重新获得Java 1.4源代码。 如果使用 debug 编译，Jad 可读的输出是可读的
信息并且不使用内部类。
缺点：与
-target jsr14类似，您需要在部署中执行额外的步骤。 图书馆也有同样的问题。将源代码更改回 Java 1.4：手动
有几个答案建议手动完成。 对于自动、重复的构建过程来说，这当然没有用，但对于一次性更改来说，这是有用的
合理的。 只需将可能的事情自动化即可。 也许看看 Antlr 来创建一个本土的转换工具。
向后移植的库：
问题是，Java5 还附带了旧版 JRE 中不可用的新库，请参阅 相关问题。 幸运的是有几个
向后移植的库为您提供 Java5 的一些功能，但无法模拟语言功能，例如泛型。
在 Java 1.4 代码中模拟 Java5 功能：
我正在考虑一些你可以做的事情来让你的生活更轻松，同时仍然使用 Java 1.4。 最重要的功能是类型安全集合，
这里有一些想法：
1,2,...,n参数及其数组的asList方法（以模拟可变参数）。1,...,n参数转换为数组）和valueOf的方法可以放入某个辅助类中。Thanks for your answers. Here is the summary of all relevant answers and my own research.
Changing the bytecode: The Retros
This is done by the "retro"-tools: Retrotranslator, Retroweaver and JBossRetro. Retrotranslator seems to be the most mature
and active of them tool. These tools scan all classes and change the bytecode to remove Java 5 and 6 features. Many Java5 features are supported, some
by using 3rd party backport libraries. This option is most popular and there is some positive feedback from users. Experiments showed that it's working as
expected. See a short overview on developerworks.
Pro: You can develop entirely in Java 5, build modules and all kind of JARs. In the end you just transform all classes to Java 1.4 and package your EAR.
This is easily done with Retrotranslator's Maven integration (
org.codehaus.mojo:retrotranslator-maven-plugin).Con: Conservative environments do not allow changed bytecode to be deployed. The result of the retro-step is not visible to any coder and can't be approved.
The second problem is fear: There might be some cryptic production problem and the retro-code is another step that might be blamed for that. App-server vendors
might refuse help due to changed bytecode. So nobody wants to take responsibility to use it in production. As this is rather a policital than a technical
problem, so I see no solution. It has happened to us, so I was looking for further options :-(
Compiling Java5 to Java 1.4: jsr14
There is an unsupported option,
javac -source 1.5 and -target jsr14which compiles the Java5 source to valid Java 1.4 bytecode. Most features likevarargs or extended for loop are translated by the compiler anyway. Generics and annotations are stripped. Enums are not supported and I don't know
about autoboxing, as the
valueOfmethods were mostly introduced in Java5.Con: Only byte code is translated, library usage is not changed. So you have to be careful not to use Java5 specific APIs (but could use Backports).
Further you have to build all modules at the same time, because for development time you propably want Java5 code with generic and annotation information.
So you have to build the entire project from scratch for Java 1.4 production.
Changing Source back to Java 1.4: Declawer
As answered in a related question, there is Declawer, a compiler extension, that works for generics and varargs, but not for enhanced for loop or
autoboxing. The generated source "is a little funky, but not too bad".
Pro: The generated source is available and can be reviewed. In worst case fixes can be made in this source. There is no "magic", because the source
is valid Java. Some people even use JAD (Java decompiler) to get the Java 1.4 source again. The output of Jad readable is readable if you compile with debug
information and don't use inner classes.
Con: Similar to
-target jsr14, you need an extra step in the deployment. Same problems with libraries, too.Changing Source back to Java 1.4: by hand
Several answers suggested doing it by hand. For an automatic, repeating build process this is of course not useful, but for one-time changes it's
reasonable. Just automate what is possible. Maybe look at Antlr for creating a home-grown conversion tool.
Backported Libraries:
The problem is, that Java5 also ships new libraries, that are not available in older JREs, see related question. Fortunately there are several
backported libraries that give you some functionality of Java5, but can't simulate language features, like generics.
Emulating Java5 features in Java 1.4 code:
I was thinking about some things you might do to make your life easier and still staying with Java 1.4. The most important features are typesafe collections,
here are some ideas:
asListmethods that allows1,2,...,narguments and an array of them (to simulate varargs).1,...,narguments to arrays) andvalueOfcan be put in some helper class.是的。 它们被称为 Retrotranslator 或 Retroweaver。 除了泛型（无论如何它只是为了编译器而存在）之外，您不能简单地“剥离 1.5 的东西”。 枚举（也许还有其他一些功能）必须替换为功能等效的代码。 这正是这些工具的作用。
Yes. They're called Retrotranslator or Retroweaver. Apart from Generics (which only exist for the compiler's sake anyway), you cannot simply "strip 1.5 stuff". Enums (and maybe also some other features) have to be replaced with functionally equivalent code. Which is exactly what those tools do.
您可以使用 JDK 1.5 功能进行编码，并在编译时以 JDK 1.4 为目标。 查看可用的 Javac 选项。 但是，大多数库现在都使用 JDK 1.5 代码，因此您将不得不使用旧库。
You can code with JDK 1.5 features and target JDK 1.4 at compile time. See available Javac options. However, most libraries are now using JDK 1.5 code, so you'll be stuck with old libs.
值得注意的是，虽然 Java 1.4 已经 EOL 一段时间了。 Java 5.0 将于 2009 年 10 月 8 日停产。如果有人向您承诺在 2010 年实现 Java 5.0，我会问为什么？！
It worth noting that while Java 1.4 has been EOL for some time. Java 5.0 will be EOL Oct 8th, 2009. If anyone is promising you Java 5.0 by 2010, I would ask why?!
要模拟 java 1.4 中的注释，您可以使用 http://xdoclet.sourceforge.net/xdoclet/index .html
To simulate annotations in java 1.4 you can use http://xdoclet.sourceforge.net/xdoclet/index.html