我想移植一些现有的 j2se 库（例如 Apache Compression 库）以用于 Blackberry 开发，但有一个问题（而不仅仅是一个问题）。
首先，大多数 java 库广泛使用 j2me 平台上通常缺少的 j2se 集合和数据类型——但这在理论上是可以解决的，这要归功于像 Apache Harmony 这样的开源 j2se api 实现。更大的问题是，Blackberry JDK 似乎基于 java 1.4，因此任何使用泛型和其他 1.5 特性（如 Enums）的代码都无法在 Blackberry 上轻松编译。
这就提出了一个有趣的问题，即是否有任何现有的工具或项目可以进行自动 1.5->1.4 转换，同时支持 j2me-bastardized 字节码 :)
我能够找到的一个项目是Retroweaver，但我不太确定该项目的活跃程度。
我敢肯定 1.5->1.4 自动转换的问题不是唯一的——那么有人有经验吗？
你试过逆向翻译吗？我读到它比 Retroweaver 做得更好。
我过去使用过retroweaver（J2SE，而不是J2ME）——它工作得非常好。使用它的代价是一些额外的运行时依赖。
2013-01-28 更新：在遇到 RetroWeaver 问题后，我已切换到RetroTranslator。
所以这就是我到目前为止所做的事情：Declawer + 一些用于枚举类生成的自定义代码。
Declawer 的一个不同之处在于，尽管它非常简单，坦率地说，有点像 hack（它依赖于 JavaC 的未记录功能），但与增强或转换的 Java 字节码相比，它的输出是实际的 Java 代码。这对于基于 Java 的移动开发来说是非常宝贵的，因为坦率地说，字节码修改/工具在 j2me 平台上的开发完全不如为 j2se 开发的那样，而且不能保证事情会以这种方式开箱即用。他们使用 j2se，这些工具已经被很多开发人员使用。
Declawer 的功能是有限的（不喜欢 1.5 枚举或自动装箱），所以我不得不添加一个 python 脚本来自动从简单的描述符生成功能与 1.5 枚举等效的类。这一代发生在构建时。
到目前为止，这解决了我的担忧，唯一的例外是找到一个对 j2me 友好的 IoC 容器用于我的应用程序（一旦你尝试了这些人，就很难放弃它们。）
但这是针对不同主题的讨论。