java - GCC 原生 Java 编译器作为典型开源 Java 项目的平台有多实用？

Question

编辑

这个问题的最初推理是一个非常严重的错误时机的情况，因此隐藏在编辑历史中。简而言之，fop 1.0即将到来，所以动力已经基本消失。此外，无论如何，真正的动机主要是挫败感。

尽管如此，这里有一个合理的问题 - GCC 原生 Java 编译器 GCJ 对于构建现实世界的开源 Java 项目(例如 FOP)有多实用？可能有多困难，可能会出现什么类型的问题？

例如，我现在了解到 gcj 实现了 JDK 1.2 语言，并且与 JDK 1.2 库“很大程度上兼容”——远远落后于 Java 6/1.6。另外，libgcj 缺少很多库，特别是与 GUI 相关的库。缺少 AWT，对于 FOP，这意味着 GUI 查看器存在问题。不过说实话，生成 .ps 或 .pdf 或其他文件并查看有什么问题吗？

Answer 1

I'm very much in the camp that still doesn't understand how Java 1.5 and Java 1.6 can be more recent than Java 2 (or are they variants of Java 2?).

将这种不一致归咎于 Sun。

有两种版本编号系统。最初的 JVM 版本控制系统为 1.0、1.1、1.2.x、1.3.x、1.4.x、1.5、1.6。 “营销驱动”的数字系统(Sun 在其发布的 Material 中使用)是 Java 2、Java 2 1.3.x、Java 2 1.4.x、Java 5.0、Java 6。因此数字“1.2”和“Java 2”意味着同样的事情，“1.3.x”和“Java 2 1.3.x”意味着同样的事情，依此类推。

发生这种情况是因为 Sun 业务人员决定他们必须拥有 Java 2.0，因为 Java 1.2(对于 IT 记者等来说)看起来只是一个次要版本。当然，这与主要版本号的既定含义相矛盾，即它只会针对主要破坏向后兼容性的 Java 版本进行更改。

最终结果是令人困惑的双版本编号，只有当您意识到后续 Java 版本有两个版本号时才有意义。 (而 SE/EE/ME 资格……以其各种表现形式……只会增加困惑。)学会忍受它。

(但是，嘿，如果您认为这很疯狂，请看看 Microsoft 的编号 Windows releases!)