对于在由超类实际实现的对象上调用的方法上的js脚本的Nashorn eval，委托给动态链接器。这将遍历类的整个层次结构，并在其所有方法上构建classWriter。如果超类包含很少的1000个方法，它仍然会发出＆＃34;方法代码太大＆＃34;错误超过JDK定义的64K限制。
var obj = SomeInitCode.getObjectOfCustomType（）;
var xyz = obj.doSomeOperation（）//这是在obj的超类上实现的方法，抽象。
Nashorn引擎然后尝试创建一个适配器，然后失败，因为在我的情况下，Abstract类及其超类上有大约6000个方法。
价：
http://skrishnamachari.wordpress.com/2014/06/18/nashorn-bug/
还有可能访问最新的Nashorn源以便能够快速调试。 Atleast找到一个黑客/验证并坚持使用，直到提供最终补丁。
答案 0 :(得分：0)
当然，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的代码在适应对象中起作用，而且确实太大了。我们可能会想出一些不同的组织构造函数的方法，但对于一个极其罕见的人们有大量课程的情况来说，这似乎是一项非常多的工作。
或者，我们可以检查是否只在真正需要时才创建适配器。您的上面的代码片段看起来在那时并非严格必要的适配器，因此在某些情况下我们可能会过于苛刻地创建适配器类。你有完整的堆栈跟踪吗？