近日，Oracle 发布了 Java 6 update 21 ，对 java.dll 的创建方式进行了一些细小但无伤大雅的变更。然而不幸的是，这个改变影响了Eclipse 的启动，对Eclipse 造成的影响要远远大于曾经的Sun 所拥有的NetBeans。
变化之处是在创建dll 时，将COMPANY_NAME=Sun Microsystems, Inc. 改为了COMPANY_NAME=Oracle Corporation。然而不幸的是，Eclipse 使用DLL 的名字来确认是否可以安全地附加非标准的-XX:MaxPermSize。如果存在该标识但却不被支持，那么某些JVM 就无法成功启动，因此就不能将-XX:MaxPermSize 放在Eclipse 的启动文件中（ eclipse.ini ），而是附加了一个新的参数–launcher.XXMaxPermSize 256m，如果 Windows 上的加载器检测到是 Sun VM，那么就会自动附加 -XX:MaxPermSize=256m。
这种自动检测发生在 C 加载器中（eclipse.exe）而非 VM，这是因为一旦运行了 VM，那么就没法修改属性了。为了能快速实现该功能（说实在的，这么做有点不妥），eclipse.exe 加载器会检查 Sun Microsystems 字符串以确定可否增加该标识。
因此，这个变化破坏了Eclipse 的加载过程，导致加载时出现OutOfMemoryError 错误。这个问题很快被报告给了Eclipse，接下来Eclipse将参数名字修改为Oracle ，该问题很快就被解决掉了。
虽然商标变更这种事是Oracle 自己的权利（甚至都没必要在发布声明中提及这一点），但这却着实地影响到了Eclipse，不仅是当前的3.6 版，还有基于3.5、3.4、及3.3 的所有IDE 与RCP。对于Eclipse 来说，需要按照顺序来修复这个问题；目前，有个补丁程序可以修复最新版Eclipse 加载器的这个问题，但还并没有直接发布，因为至少要考虑到Eclipse 3.5 与3.4，为的是确保兼容性。
Oracle 因快速的问题解决速度而备受称赞。虽然他们并不需要解决这个问题，但还是在几天内就解决了，随后的 Java 构建版本也会修复这个问题（是否要重新构建 6u21 抑或是 6u22 还不太确定）。与此同时，如果你遇到了 Eclipse 的问题，同时最近又安装了 Java 6u21（或是自动更新的），那么可以降级到 Java 6u20 或是按照FAQ 的指导重新启用permgen size。
查看英文原文： Eclipse and Java 6u21 problems
