将 Java 代码 1.5 降级到 1.4（奖励积分：J2ME、Blackberry！！！）
我想移植一些现有的 j2se 库（例如 Apache 压缩库）以用于 Blackberry 开发，但有一个问题（而且不仅仅是一个）。
首先，大多数 java 库广泛使用 j2se 集合和数据类型，而这些集合和数据类型通常在 j2me 平台上缺失 - 但由于 Apache Harmony 等开源 j2se api 实现，这在理论上是可以解决的。 更大的问题是，Blackberry JDK 似乎基于 java 1.4，因此任何使用泛型和其他 1.5 功能（如枚举）的代码都无法在 Blackberry 上轻松编译。
这就提出了一个有趣的问题，即是否有任何现有工具或项目可以进行自动 1.5->1.4 转换，同时支持 j2me-bastardized 字节码:)
我能找到的一个项目是 Retroweaver，但我不太确定该项目有多活跃。
我确信 1.5->1.4 自动转换的问题并不是唯一的 - 那么有人有这方面的经验吗？
I want to port some existing j2se libraries (e.g. Apache Compression libs) to use for Blackberry development, but there is a catch (and not just one).
First, most java libs extensively use j2se collections and data types that are typically missing on j2me platforms — but that's theoretically solvable thanks to open-source j2se api implementations like Apache Harmony. The bigger problem is that, it seems, Blackberry JDK is based on java 1.4, so any code that uses generics and other 1.5 features, like Enums, is not effortlessly compilable on Blackberry.
Which raises an interesting question of whether there are any existing tools or projects out there that would do automatic 1.5->1.4 conversion, while supporting j2me-bastardized bytecode :)
One project I was able to find is Retroweaver, but I'm not quite sure how active that project is.
I'm sure the problem of 1.5->1.4 automatic conversion isn't unique -- so does anybody have any experience with it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您尝试过 Retrotranslator 吗？ 我读到它比 Retroweaver 做得更好。
Have you tried Retrotranslator? I read that it does a better job than Retroweaver.
这是其他东西我在堆栈溢出上找到了：
这绝对是值得尝试的。
Here's something else I found here on stack overflow:
Which absolutely makes sense to try.
我过去使用过 Retroweaver（J2SE，不是 J2ME）——它工作得非常好。 使用它的成本是一些额外的运行时依赖项。
更新 2013-01-28：在使用 RetroWeaver 遇到问题后，我已切换到 RetroTranslator 。
I've used retroweaver in the past (J2SE, not J2ME) - it worked really well. The cost of using it is a couple extra runtime dependencies.
Update 2013-01-28: After running into problems with RetroWeaver, I've switched to RetroTranslator.
所以这就是我到目前为止所做的：Declawer + 一些用于生成枚举类的自定义代码。
Declawer 的一个与众不同之处在于，虽然它非常简单，而且坦率地说，有点像 hack（它依赖于 JavaC 的未记录功能），但与增强或转换的 Java 字节码相比，它的输出是实际的 Java 代码。 这对于基于 java 的移动开发来说非常宝贵，因为坦率地说，字节码修改/检测根本不像为 j2se 那样为 j2me 平台开发，并且不能保证事情会按开箱即用的方式工作他们使用 j2se，这些工具已经被相当多的开发人员使用。
Declawer 的功能有限（不喜欢 1.5 枚举或自动装箱），因此我必须添加一个 python 脚本来从简单的描述符自动生成功能与 1.5 枚举等效的类。 这一代发生在构建时。
这解决了我到目前为止的担忧，唯一的例外是找到一个好的 j2me 友好的 IoC 容器用于我的应用程序（一旦你尝试了这些家伙，就很难放弃它们。）
但这是针对不同线程的讨论。
So here's what I ended up doing so far: Declawer + some custom code for enumeration classes generation.
The one differentiating thing about Declawer is that, although it's very simple and, frankly, a bit of a hack (it relies on an undocumented capability of JavaC), its output is actual Java code as compared to enhanced or converted Java bytecode. That's very precious for mobile java-based development as, frankly, bytecode modification/instrumentation is not at all as developed for j2me platforms as it is for j2se, and there are just no guarantees that things are going to work out of the box the way they do with j2se where these tools have already been used by quite a few developers.
Declawer's functionality is limited (no love for 1.5 enums or autoboxing), so I had to add a python script to automatically generate classes equivalent in functionality to 1.5 enums from simple descriptors. This generation happens at build time.
This addresses my concerns so far, with the only exception of finding a good j2me-friendly IoC container to use for my app (once you try these guys, it's so hard to give them up.)
But that's a discussion for a different thread.
这是我发现的另外两个工具（从 Retrotranslator 的页面链接到）：
Here's two more tools that I found (linked to from Retrotranslator's page):