如何在 MacOS 上获得干净的 Java VM？
在 MacOS 上（至少在 SnowLeopard 上），java 命令无条件地将额外的 jar 添加到类路径：
/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/.compatibility/14compatibility.jar。
该 jar 包含 Apache Xerces+Xalan 的一个版本，未重命名。这可能会导致尝试显式使用这些库的某些其他版本的应用程序出现混乱的结果，特别是在 Servlet 容器中的 Web 应用程序中。
我试图通过使用 MacPorts 中的 OpenJDK 来避免这种情况，但 MacPorts 构建失败了。
除了删除 JAR 文件这种明显的暴力行为之外，还有人想出了其他办法吗？在一个博客上推荐了它，但我担心如果没有它，某些 Apple 组件或其他组件将会失败。
On MacOS (at least on SnowLeopard), the java command unconditionally adds an extra jar to the classpath:
/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/.compatibility/14compatibility.jar.
This jar contains a version of Apache Xerces+Xalan, unrenamed. This can cause chaotic results for applications that are trying explicitly to use some other versions of these libraries, particularly in webapps in servlet containers.
I tried to avoid this by using OpenJDK from MacPorts, but the MacPorts build failed for it.
Has anyone worked out some other recipe, other than the obvious violence of deleting that JAR file? It's recommended on one blog, but I fear that some Apple component or another will fail without it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
重命名 14compatibility.jar 后，我没有遇到任何问题。也许你可以尝试这样做。如果任何东西严重损坏，您可以将其移回原来的位置。
I haven't had any problems after renaming 14compatibility.jar. Perhaps you could try doing that. If anything breaks horribly, you could move it back in its original place.
我相信这里的最终王牌是 -Xbootclasspath/p:foo.jar 。这使您可以在引导类加载器前面添加一个 .jar。这应该使它优先于我能想象的任何事情。例如，您可以通过这种方式替换 java.lang.String。
I believe the ultimate trump card here is -Xbootclasspath/p:foo.jar . This lets you prepend a .jar to the bootstrap classloader. This should make it take precedence over anything I can imagine. For example you can replace java.lang.String this way.