当前位置: 首页 > 知识库问答 >
问题:

Java8 Javascript Engine向后兼容

屠锐
2023-03-14

我正在我的项目中尝试Java8,我被困在与我的构建过程相关的错误中。

我正在使用ANT脚本,在某个时刻,我正在使用一些javascript(嵌入到ANT中)来执行一些特定于构建的操作。导致错误的脚本部分如下所示:

<script language="javascript"> 

        <![CDATA[

        importClass(java.io.File);
        importClass(java.io.FileReader);
                    ...
                    ]]>
</script>

该项目使用Java 7或Java 6构建得很好,但在使用Java 8时,它会给我带来一些错误。这些错误与JS引擎的升级有关。

特别是我得到了以下例外:

javax。剧本ScriptException:ReferenceError:“importClass”未在at行中定义

通过谷歌搜索,我发现它与JDK中的以下问题有关

[#JDK-8025132]

我尝试了评论中的建议,但没有运气。

如何使Java8Nashorn引擎与RhinoJS引擎兼容?

共有1个答案

温亮
2023-03-14

一种方法是包括

load("nashorn:mozilla_compat.js");

另一方面,您可以使用java。伊奥。文件,java。伊奥。文件阅读器。。。直接进口。

var File = java.io.File;
var FileReader = java.io.FileReader;

这与Rhino向后兼容。

 类似资料:
  • ngrok承诺有关其接口的兼容性和稳定性,以便您可以自信地构建集成顶部,知道在升级到较新版本时期望的更改。 兼容性承诺 Point Release (2.0.0 -> 2.0.1) - ngrok承诺在点发布之间没有突破性的变化 Minor Version Change (2.0 -> 2.1) - ngrok可能会进行小的更改,打破兼容性的次要版本更改。 ngrok承诺,任何破坏性更改将由一个版

  • 确保您可以轻松顺利地升级您的应用程序,这对我们是很重要的。这就是为什么我们只在主 要版本里程碑才会打破兼容性。你可能熟悉 语义版本控制 ,这 就是我们在所有的 CakePHP 项目中使用的通用准则。总之,语义版本控制意味着只有主要版 本(比如2.0,3.0,4.0)可以打破向后兼容性。次要版本(比如2.1,3.1,3.2)可能会引入新 的功能,但不能破坏兼容性。错误修复版本(比如2.1.2,3.0

  • Google正在弃用Google Cloud消息传递,转而采用Firebase Cloud消息传递: Firebase云消息传递(FCM)是GCM的新版本。它继承了可靠和可扩展的GCM架构体系,加上新功能!查看常见问题解答了解更多信息。如果要在新应用中集成消息,请从FCM开始。强烈建议GCM用户升级到FCM,以便在今天和将来受益于新的FCM功能。 根据我在服务器上进行的一些测试,FCM URL(h

  • 问题内容: 我在一个应用程序中工作,我们需要将对象保存为XML格式,并在以后需要时加载它们。为此,我使用JAXB将XML编组和解编回Java类。 我的问题是我必须在某个时候更改Java模型(通过添加,重命名或删除属性),结果,我将拥有不兼容的保存XML,无法将其绑定回新的类形式。 为了解决这个问题,每次必须进行更改时,我都会在一个新程序包(以其版本命名)下复制所有类的副本,并应用所请求的更改。并且

  • 问题内容: 我的理解是,为了维护源代码兼容性,Java从未将新方法引入公共接口,因为这破坏了实现接口的现有客户端。 Java发行说明说明 通常,该政策如下,但以下列出的不兼容之处除外: 维护版本(例如1.4.1、1.4.2)未引入任何新的语言功能或API。他们将保持彼此之间的源兼容性。 功能版本和主要版本(例如1.3.0、1.4.0、5.0)保持向上但不向下的源兼容性。 然而,包和继续发展,并介绍

  • 查看v3规范,新消息似乎是有效的,难道旧的提供程序库(v3.2.13)不支持它吗?我查看了代码,发现了这个commit,在我看来,这似乎是引入更改的地方。 从我的测试来看,新的提供程序库(3.5.12)可以处理新旧格式,但如果类路径中同时存在新的提供程序库和旧的使用者库,http契约测试将失败,并出现运行时错误。 问题: