|
|
6 回复 | 直到 14 年前
|
1
1
|
|
|
2
4
之所以会这样,是因为Sun业务人员决定他们必须拥有java2.0,因为java1.2(对It记者等)看起来只是一个小版本。当然,这与主要版本号的既定含义相矛盾,主要版本号的含义是,它只会随着Java的主要版本而改变 中断向后兼容性 最终的结果是一个令人困惑的双版本编号,只有当您意识到以后的Java版本有两个版本号时才有意义(以及SE/EE/ME资格。。。各种各样的表现。。。只是增加了困惑。)只要学会接受它。 (但是,如果你觉得这很疯狂,看看微软的 Windows releases |
|
|
3
1
您可能会发现的问题主要与GCJ中未实现的api或bug库实现有关。还有一些语言特性没有得到很好的支持,比如反射。
|
|
|
4
1
在您尝试使用某个很久没有发布的项目的情况下,值得查看项目邮件列表。 这里有一个 "fop-dev" 邮件列表。首先,注意邮件列表是活动的。很多帖子。第二,如果您查看2010年7月的邮件,您将看到他们投票同意接受fop1.0发布分支。我不太清楚这意味着什么,但我怀疑这意味着1.0将很快发布。
编辑 我不相信“依赖地狱”有那么糟糕。一方面,您(作为主要开发人员)应该能够找出工作组件的某些版本组合。然后你说“这些是我们推荐/支持的版本”。如果人们想使用不同的组合,那是他们的责任。 另一方面,如果你使用 Maven 作为构建框架,依赖关系在项目POM文件中显式声明。如果您确保发布到公共存储库,并且您发布的工件仅依赖于正确发布/发布的第三方工件,那么您的客户应该不会有任何困难,无论是直接构建您的软件,还是通过Maven存储库下载。如果他们想修补依赖关系,他们可以这样做。 编辑2
编辑3 我只想补充一点,您还可以选择使用/建议人们使用OpenJDK。OpenJDK是最近所有主流Linux发行版AFAIK的一部分。 |
|
|
5
0
看到了吗 this |
|
6
0
因为这似乎是“我需要一个预先打包的FOP版本,我基本上不想听到一个错误报告”,而不是“我们需要FOP作为另一个产品的一部分,这将有相当长的时间开发人员的关注,这是至关重要的,这是正常工作”,我强烈建议您采用主流方式,创建一个传统的基于字节码的包,它需要sunjvm来运行。
|
