Nashorn bug JDK8u40“方法代码太大”

Question

在一个对象上调用的方法上的 js 脚本的 Nashorn eval 实际由其超类实现，委托给动态链接器。这将遍历类的整个层次结构并在其所有方法上构建一个 classWriter。如果超类包含几千个方法，它仍然会发出“方法代码太大”错误，超过 JDK 定义的 64K 限制。

var obj = SomeInitCode.getObjectOfCustomType();

var xyz = obj.doSomeOperation() // 这是在 obj 的超类 Abstract 上实现的方法。

Nashorn 引擎然后尝试创建一个适配器，但随后失败，因为在我的例子中，抽象类及其超类上有大约 6000 多个方法。

参考：

http://skrishnamachari.wordpress.com/2014/06/18/nashorn-bug/

还有可能访问最新的 Nashorn 源代码以便能够快速调试。至少找到一个 hack/validate 并让它一直供我们使用，直到提供最终补丁。

Answer 1

当然，最新的 8u 分支开发者存储库位于 http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn。不过，它很快就会成为 8u60 的开发阶段，但是您可以在此处获得 8u40 代码：http://hg.openjdk.java.net/jdk8u/jdk8u40-dev/nashorn。到目前为止，Nashorn 的 FWIW、8u 和 9 代码几乎完全相同（到目前为止，我们向后移植了从 9 到 8u 的所有内容，除了一些实际上不会影响外部可观察行为的解析器更改）。

说到你的问题：如果我们需要为 +6000 个方法的 Java 类生成一个 JS-to-Java 适配器类，那么它确实会失败，因为该类的构造函数将具有查找 6000 个 JS 的代码适应对象中的函数，这确实太大了。我们可能会想出一些不同的方式来组织构造函数，但对于极少数人拥有庞大类的情况来说，这似乎是一项非常艰巨的工作。

或者，我们可以检查我们是否只在真正需要时才创建适配器。您上面的代码 sn-p 看起来此时适配器并不是绝对必要的，因此在某些情况下我们可能过于渴望创建适配器类。你有完整的堆栈跟踪吗？